Home Documentation Authentication and User Management Service Backend-for-Frontend Pattern

Backend-for-Frontend Pattern

Last updated: January 2026

The Agglestone Authentication and User Management Service supports Backend-for-Frontend (BFF) authentication patterns, providing a secure way to handle authentication for web applications where tokens should never be exposed to the browser. This pattern is ideal for applications that require enhanced security and want to keep sensitive authentication tokens completely server-side. However, BFF does have a downside, as all calls to APIs need to be proxied through your backend.

In a BFF architecture, your backend service acts as an intermediary between your frontend application and the Agglestone Authentication and User Management Service. The frontend code never directly interacts with the authentication service, and authentication tokens never leave your backend infrastructure. This provides significant security benefits while maintaining a smooth user experience.

How BFF Authentication Works

When using the Backend-for-Frontend pattern with the Agglestone Authentication and User Management Service, the authentication flow is initiated by your backend services. Your frontend application communicates only with your own backend, never directly with the authentication service.

The authentication process begins when a user initiates login from your frontend application. Instead of redirecting the user to the authentication service directly, your frontend sends the login request to your backend service. Your backend then handles the OAuth2 authorization code flow with the Agglestone Authentication and User Management Service, exchanging authorization codes for tokens, and managing refresh tokens as needed.

Once authentication is complete, your backend maintains the session state. The frontend receives session information (such as a session cookie or session identifier) that it can use to identify authenticated requests, but the actual JWT access tokens and refresh tokens remain securely stored on your backend server.

Token Security

The fundamental principle of Backend-for-Frontend authentication is that authentication tokens never reach the user’s browser. This means:

  • Access tokens stay server-side – JWTs issued by the Agglestone Authentication and User Management Service are stored and managed entirely within your backend infrastructure
  • Refresh tokens remain secure – Refresh tokens are handled by your backend service, never exposed to client-side JavaScript or stored by a user’s browser
  • Reduced attack surface – By keeping tokens server-side, you eliminate the risk of token theft through cross-site scripting (XSS) attacks, browser extensions, or other client-side vulnerabilities
  • Enhanced security – Even if your frontend application is compromised, attackers cannot access authentication tokens because they simply aren’t present in the browser

This approach provides the highest level of security for web applications, especially those handling sensitive data or operating in high-security environments.

API Call Proxying

Because authentication tokens never leave your backend, all API calls to Agglestone services must be made through your backend infrastructure. This means your backend service acts as a proxy for all interactions with Agglestone APIs.

When your frontend needs to access user information, group data, or any other Agglestone service, it makes a request to your backend. Your backend then uses the stored authentication tokens to make the actual API call to the Agglestone service, retrieves the data, and returns it to your frontend. This proxying pattern ensures that tokens remain secure while still allowing your frontend to access the data it needs.

Proxying Agglestone API Calls

Your backend will need to proxy calls to various Agglestone APIs, including:

  • User Management APIs – When your frontend needs to display user information, update user profiles, or manage user accounts, these requests go through your backend
  • Group Management APIs – Any operations involving groups—listing groups, adding users to groups, or checking group membership—are proxied through your backend
  • Authentication Settings APIs – If your application needs to read or update authentication settings, these calls are handled by your backend
  • Any Other Agglestone APIs – All interactions with Agglestone services follow the same pattern: frontend requests go to your backend, and your backend makes authenticated calls to Agglestone
  • Customer APIs Secured with Agglestone JWTs – When your frontend needs to call your own APIs that require Agglestone JWT tokens for authentication or access management, these requests must also go through this same backend. Your backend uses the stored JWT to authenticate with your customer APIs on behalf of the user

This proxying requirement is a natural consequence of the BFF pattern. By centralizing all authenticated API calls through your backend, you maintain complete control over token usage and ensure that sensitive credentials never leave your server infrastructure.

Session Management

In a Backend-for-Frontend architecture, your backend is responsible for managing user sessions. When a user successfully authenticates, your backend creates a session and associates it with the user. The frontend receives a session identifier (typically through a secure, HTTP-only cookie) that it can include with subsequent requests.

Your backend maintains the mapping between session identifiers and the actual authentication tokens. When the frontend makes a request with a session identifier, your backend looks up the associated tokens, validates the session, and uses the tokens to make authenticated calls to Agglestone services on behalf of the user.

This session management approach gives you complete control over session lifecycle. You can implement custom session expiration policies, handle concurrent session limits, and provide session management features that match your application’s requirements.

Cookie Security Requirements

For Backend-for-Frontend authentication to work securely, your backend and frontend must be on the same domain, and session cookies must be properly configured.

Your backend service must be deployed on the same domain as your frontend application (for example, if your frontend is at https://app.example.com, your backend should be at https://app.example.com/api). This is necessary because browsers enforce the same-origin policy for cookies – cookies can only be sent to the same domain where they were set. Additionally, your frontend must configure API calls to be sent “with credentials” to ensure the session cookie is included in requests.

Session cookies must be configured with both the Secure and HttpOnly flags. The Secure flag ensures cookies are only sent over HTTPS, preventing interception over unencrypted connections. The HttpOnly flag prevents client-side JavaScript from accessing the cookie, protecting against cross-site scripting attacks. Together, these settings ensure session identifiers remain protected from both network-based and client-side attacks.

Benefits of BFF Authentication

The Backend-for-Frontend pattern provides several key advantages:

  • Maximum Security – Tokens never leave your backend, eliminating client-side token exposure risks
  • Centralized Control – All authentication logic and token management happens in one place, making it easier to implement security policies and audit authentication events
  • Flexible Session Management – You have complete control over how sessions work, including expiration, revocation, and concurrent session handling
  • Simplified Frontend – Your frontend application doesn’t need to handle token storage, refresh logic, or token expiration- it just makes requests to your backend
  • Better Compliance – Keeping tokens server-side can help meet security compliance requirements that restrict sensitive data in browsers

When to Use BFF Authentication

Backend-for-Frontend authentication is ideal for:

  • High-security applications – Applications handling sensitive data or operating in regulated industries
  • Applications requiring custom session management – When you need fine-grained control over session lifecycle and behavior
  • Multi-service architectures – When your backend needs to coordinate authentication across multiple services or APIs
  • Applications with strict security policies – Organizations that require tokens to never be exposed to client-side code

The BFF pattern provides the highest level of security for web applications while maintaining the flexibility to build rich, interactive user experiences.

—

Ready to integrate? Check out the Integration Guide to get started with Backend-for-Frontend authentication.