Authentication Features

Last updated: January 2026

The Agglestone Authentication and User Management Service provides a comprehensive set of authentication features designed to keep your applications secure while providing a smooth user experience. All features are built on industry standards, making integration straightforward with standard OAuth2 and OpenID Connect client libraries.

Your tenant has complete isolation, with your users, authentication settings, security policies, and tokens all tenant-scoped and completely separate from other tenants. This ensures that your authentication configuration and user data remain private and secure.

OAuth2 and OpenID Connect Flows

The Agglestone Authentication and User Management Service fully implements the OAuth2 authorization code flow with PKCE (Proof Key for Code Exchange) for enhanced security. We also support OpenID Connect, which adds an identity layer on top of OAuth2, providing you with user identity information in addition to access tokens.

The best part? Everything is discoverable through the OpenID Connect Discovery endpoint. This means you can use standard client libraries like oidc-client-ts@^3.4.1 and they’ll automatically discover all the endpoints, supported scopes, and public keys needed for token verification. No manual configuration required!

All OAuth2 and OpenID Connect flows are tenant-aware. Each tenant has its own discovery endpoint, authorization endpoints, and token endpoints, ensuring complete isolation between tenants.

Multi-Factor Authentication (MFA)

Add an extra layer of security to your applications with time-based one-time passwords (TOTP). When MFA is enabled, users can set it up by scanning a QR code with their favorite authenticator app—whether that’s Google Authenticator, Microsoft Authenticator, Authy, or any other TOTP-compatible app.

The setup process is simple: users scan the QR code, enter a verification code, and they’re all set. From that point forward, they’ll be prompted for their authenticator code during login, significantly reducing the risk of unauthorized access even if passwords are compromised.

Password Management

Password Reset During Login

Sometimes you need users to change their password—maybe it’s their first login, or maybe you’ve detected a security issue. The Agglestone Authentication and User Management Service can enforce password reset during the login flow, ensuring users update their credentials before accessing your application.

Forgot Password Flow

Users forget passwords—it happens! The Agglestone Authentication and User Management Service includes a complete forgot password flow that sends secure, time-limited reset tokens to users’ email addresses. Users click the link, set a new password, and they’re back in action. All without requiring any administrator intervention.

Password Reset from Your Application

Want to let users change their password from within your application? You can do that too! Authenticated users can request a one-time reset token that allows them to change their password directly from your app’s settings page, providing a seamless user experience.

Password Requirements

Enforce strong passwords by configuring:

  • Minimum password length – Set how long passwords must be
  • Character requirements – Optionally require uppercase letters, lowercase letters, numbers, and/or symbols

These requirements are enforced both when users create new passwords and when they reset existing ones, ensuring consistent security across your user base.

Security Controls

MFA Attempt Limits

Protect against brute-force attacks on MFA codes by configuring the maximum number of failed attempts allowed. Once the limit is reached, users are temporarily locked out for a configurable period before they can try again. This gives you control over the balance between security and user experience.

Password Attempt Limits

Similarly, you can configure how many failed password attempts are allowed before a user is locked out. Set both the maximum attempts and the lockout duration to match your security requirements. This helps prevent automated attacks while still allowing legitimate users to recover from typos.

Login Flexibility

Not all applications use the same login method. Some use email addresses, some use usernames, and some support both. The Agglestone Authentication and User Management Service lets you configure how users can log in:

  • Email only – Users must log in with their email address
  • Username only – Users must log in with their username
  • Email or Username – Users can use either

Choose the option that best fits your application’s user model.

Token Management

All tokens issued by the Agglestone Authentication and User Management Service are tenant-scoped and signed. JWTs include tenant information, and refresh tokens are associated with a specific tenant, ensuring complete isolation between different tenant authentication sessions.

JWT Expiration

Access tokens (signed JWTs) issued by the Agglestone Authentication and User Management Service can be configured with a custom expiration time. The default is 15 minutes, but you can adjust this to match your application’s needs. Shorter expiration times provide better security, while longer times reduce the frequency of token refreshes.

Refresh Token Expiration

Refresh tokens have their own configurable expiration time, with a default of 30 days. This controls how long users can stay logged in without re-entering their credentials. Adjust this based on your security requirements and user experience goals.

Refresh Token Security

The Agglestone Authentication and User Management Service provides multiple layers of security for refresh tokens:

  • Replay Protection – If a refresh token is used after it’s been rotated (replaced with a new one), you can configure the Agglestone Authentication and User Management Service to invalidate all refresh tokens for that user. This prevents token replay attacks and ensures that if a token is compromised, it can’t be used indefinitely.
  • IP Address Restrictions – You can restrict token refresh to only work from IP addresses the user has previously logged in from. If someone tries to refresh a token from a new location, they’ll be required to do a full login again. This adds an extra layer of protection against token theft, while minimising inconvenience to users.
  • IP Address Binding – For even stricter security, you can bind refresh tokens to the specific IP address where they were issued. If the IP address changes (even to a previously used IP Address), the token becomes invalid and the user must log in again. This is perfect for high-security applications where you want to ensure tokens can’t be used from different locations.

Allowed Origins

Control which websites can interact with your authentication service by configuring allowed origins. When the allowed origins list is empty, all sites are allowed. When origins are specified, only requests from origins on your allowlist will be accepted, preventing unauthorized websites from attempting to use your authentication endpoints. This is an important security measure for protecting against cross-site request forgery (CSRF) attacks.

Customizable UI

Your authentication pages should feel like part of your application, not a third-party service. The Agglestone Authentication and User Management Service allows you to customize the HTML for:

  • Login pages – Match your application’s branding and design
  • Password reset pages – Keep users in your visual world even when resetting passwords
  • MFA pages – Make multi-factor authentication feel seamless

All custom HTML is fully supported, so you can use your own CSS and design elements. For security reasons, customer-provided JavaScript is not allowed on these pages. The Agglestone Authentication and User Management Service provides the authentication logic; you provide the look and feel.

Multi-Tenant Architecture

The Agglestone Authentication and User Management Service is built on a multi-tenant architecture where each tenant operates in complete isolation. This means:

  • Tenant-Scoped Users – Users belong to specific tenants and can only authenticate within their tenant
  • Independent Configuration – Each tenant configures their own authentication settings, password policies, MFA requirements, and security controls
  • Isolated Tokens – All tokens (JWTs and refresh tokens) are tenant-scoped and cannot be used across tenant boundaries
  • Separate Customization – Each tenant can customize their login pages, password reset pages, and MFA pages independently
  • Independent Security Policies – Password requirements, attempt limits, token expiration, and all security settings are configured per tenant

This architecture ensures that your authentication data and configuration remain completely private and secure, while allowing you to customize the authentication experience to match your brand and security requirements.

Ready to see how users and groups work? Check out User and Group Features.