Overview

RFC 10017’s token-mediating backend keeps the OAuth flow and refresh token with a confidential server, then returns an access token so the browser can call the resource server directly. This avoids full BFF proxying but intentionally exposes access authority to browser code, which can steal it, use it directly, or request a fresh one through the mediator. The backend must protect the release endpoint with CSRF controls, apply scope and audience policy, use downscoping when supported, and manage session and refresh state. The pattern is justified by a genuine direct-call requirement, not proxy convenience.

Learning outcomes

Token mediation keeps refresh authority server-side but deliberately exports access authority to the browser.
It avoids proxying every resource request, but malicious browser code can steal or directly use the access token.
A token-release endpoint needs CSRF, session, scope, and audience controls; direct calls must be a genuine requirement.

Keywords

RFC 10017Token mediationAccess tokenRefresh tokenScopesDPoP

The Middle Position: What a Token-Mediating Backend Gives Up

RFC 10017’s token-mediating backend is designed for a specific compromise: keep the long-lived refresh authority on a server, but let the browser call the resource server with an access token. This chapter examines the asset that crosses that boundary and uses it to answer a narrower question than “is the backend safer?”—which attacks disappear, which remain, and when the convenience of direct browser-to-resource-server calls justifies the loss compared with a BFF.

The backend keeps the refresh authority, not every request

A token-mediating backend handles the OAuth flow as a confidential client. It is therefore different from a browser-only client at the point where the authorization code becomes tokens. But unlike a BFF, it does not forward every resource request. Once the backend has obtained an access token, it makes that access token available to the browser application, which uses it to call the resource server directly.

The login sequence begins in much the same way as a BFF sequence. The browser loads the application and checks the backend for an active session. If there is no session, the application navigates to a backend endpoint that starts the Authorization Code flow with PKCE. The backend redirects the browser to the authorization server. After authorization, the browser delivers the code to the backend, and the backend exchanges it at the token endpoint with its client credentials and PKCE verifier.

The difference appears after the exchange. The backend associates the resulting credentials with the user’s cookie-based session, then returns a response that allows the application to resume. When the application checks the session again, the backend includes an access token in the response. The refresh token remains associated with the backend’s session; the access token crosses into the frontend’s execution environment. The browser then sends that access token directly to the resource server rather than sending an application request to the backend for every operation.

That creates two distinct paths through one system. The session cookie lets the backend identify the session and recover the refresh authority. The access token lets the browser act as the client of the resource server. One path is mediated by the backend; the other is deliberately exposed to the browser so the frontend can make direct calls.

When the access token expires or the resource server rejects it, the application can contact the token-mediating backend to request a new one. The backend uses the session cookie to find the refresh token, makes a refresh request as a confidential client, and returns a fresh access token to the application. The browser does not need to possess the refresh token to continue operating. This is a meaningful improvement over a browser-only client because the credential that can repeatedly create access tokens is not directly available to ordinary application code.

The BFF makes a different choice at the same boundary. Its browser request carries session state to the BFF, and the BFF attaches the access token to the outbound resource-server request. The access token does not return to the frontend as a credential for later direct use. In token mediation, by contrast, the frontend must receive and use the access token. The backend has reduced the amount of authority crossing the boundary, but it has not removed access authority from the browser.

Published by DeepMox

FAQ

Which token crosses the browser boundary in token mediation?

The access token crosses into the browser, while the refresh token remains associated with the backend’s session. The browser then uses the access token for direct resource-server requests.

Why must a token mediator check requested scopes?

It must check scopes to avoid returning a cached access token with more authority than the frontend needs. When the authorization server supports it, the backend should use the refresh token to request a narrower token.

Does token mediation provide the same boundary as a BFF?

No. Token mediation returns an access token for direct browser use, whereas a BFF retains the token while proxying the resource request. The mediator therefore accepts access-token exposure to avoid full proxying.

Previous12 minRFC 10017 BFF Security Boundary

Next21 minRFC 10017 Browser-Only OAuth

RFC 10017 Token-Mediating Backend

The Middle Position: What a Token-Mediating Backend Gives Up

The backend keeps the refresh authority, not every request

FAQ