Skip to content
Adoption guide

Give application teams a maintained foundation for browser and API security.

Your frontend team needs to deliver application behaviour and a clear user experience. Authentication also brings token handling, session expiry, API access and the coordination needed when an application runs across multiple instances.

← All scenarios and guides

The ProAuth product suite includes .NET packages for the BFF, OAuth/OIDC clients and ASP.NET Core APIs. They provide reusable implementations that your team configures within its application architecture.

Token handling in the backend
BrowserSPA
Session cookie
BFFIn your application
Token + sender proof¹
APIValidation + permissions

ProAuth ↔ BFFOIDC / OAuth

Server-side storageTokens, tickets and coordinated renewal

¹ When DPoP or mTLS is configured; the API must validate the proof.

Architecture overview, not a complete protocol flow. The browser uses a session cookie. The BFF uses OIDC/OAuth with ProAuth and calls the API with a token and, when configured, sender proof. The API validates these and enforces permissions. Tokens and tickets live in configured server-side storage.

Keep OAuth token handling in the backend

A Backend for Frontend (BFF) handles the OAuth flow and forwards API calls on behalf of the browser application. With server-side ticket and token storage configured, the browser uses a session cookie while OAuth tokens remain in the backend.

Frontend developers work with application endpoints and the user information exposed by the BFF. They still implement sign-in and sign-out interactions, session-expiry behaviour and the required anti-forgery request handling. API permissions remain enforced by the backend.

Account for production behaviour

The BFF packages provide session and token-store integrations, proxying and token renewal. Multi-instance deployments need shared storage, coordinated locking and appropriate key configuration so requests can be handled consistently across instances.

Your team configures routes, trusted proxies, client registration, storage and key management, then validates the complete application. ProAuth documentation and CLI helpers assist with configuration and key generation; ongoing key storage and rotation remain operational responsibilities.

Introduce token protection across clients and APIs

Sender-constrained tokens bind token use to a client's cryptographic key or certificate. The client supplies the required proof, and the API validates it. ProAuth's client and ASP.NET Core resource-server packages support the corresponding integration, including DPoP proof replay detection.

Start with selected applications. APIs can accept existing bearer-token clients alongside correctly validated sender-constrained clients during a migration. Enforce the required policy once the relevant clients are ready. Multi-instance replay detection needs shared state.

PAR and JAR provide additional ways to protect authorisation requests. ProAuth's FAPI 2.0 profile is opt-in and requires the corresponding client and API configuration. Choose the controls appropriate to the application and validate the full flow; enabling a profile is not a certification claim.

The next step

Evaluate the approach in your project.

Trace one browser-to-API request, including sign-in, token renewal, logout and session expiry. Identify where tokens, keys, tickets and replay state live, and who maintains them.

Discuss your browser and API architecture