Part 2 of 3 on authentication architecture | FusionAuth

/ Blog

Light<br>Dark<br>System

Log In

Get a demo

Open main menu

Education<br>Security<br>Token-Mediating Backend: An alternative to the BFF architecture<br>Learn how a token-mediating backend (TMB) is less secure than backend-for-frontend (BFF) and when to use TMB. Part 2 of 3 in the architecture-driven auth series.

Authors

Kim Maida<br>Nathan Contino

Published: May 7, 2026

This post discusses the Token-Mediating Backend (TMB) authentication architecture for OAuth 2 applications. It covers how secure TMB is, when to use it, and how to implement it.

tip<br>This is part two of a three-part series on OAuth architectures. Please read part one if you haven't already, so you understand how the Backend-for-Frontend (BFF) architecture works, since TMB is a variation of BFF.

Understanding TMB Architecture#

TMB works just like Backend-For-Frontend (BFF), with one major difference: TMB stores access tokens in the frontend (desktop, mobile, or web app). Since the access token is available in the browser, the browser can call a resource server directly, instead of proxying resource server calls through the backend.

For more information about TMB, see the Internet Engineering Task Force (IETF) OAuth 2.0 for Browser-Based Applications draft.

TMB Security#

TMB is less secure than BFF because access tokens in the browser are vulnerable to exfiltration by malicious JavaScript packages and cross-site scripting (XSS). However, it's much more secure than serverless web apps, which use the Browser-Based OAuth Client (BBOC) architecture, as they have no secure backend at all.

You can think of the security architecture spectrum like so: BFF (most secure) > TMB (less secure) > BBOC (least secure).

Both BFF and TMB are vulnerable to fraudulent requests if an attacker manages to inject malicious JavaScript into the browser (client hijacking). But BFF prevents the attacker from using the token from the attacker's computer (token exfiltration) while TMB does not.

TMB has two of the security advantages of BFF:

Same-site HTTP-only session cookies (as well as PKCE checks and OIDC nonces) prevent CSRF attacks.

Refresh tokens stay on the server, hidden from attackers.

In the TMB frontend, the access token can't be kept in an HTTP-only cookie, because the browser needs the token for calls to resource servers. Since the access token has to be stored in the browser's local storage or application memory, it's vulnerable to exfiltration by XSS attacks, like malicious npm packages or unsanitized HTML inputs.

TMB is slightly more secure than BBOC because of the server-side refresh token — if you follow best practices.

You can set a very short expiry period for your access tokens (ten minutes or less) to minimize the attack window. The frontend can silently ask the server for a new access token generated from the server-side refresh token every few minutes, so the user does not need to log in again. If you detect unauthorized use of an access token, you can revoke the refresh token and force a user to log in again.

Of course, if an attacker has managed to insert malicious JavaScript into your frontend, they can steal the access tokens again and again, so access token timeouts won't protect you. However, once the user closes their browser, all fraudulent requests must pause. For this reason, mobile and desktop apps are safer than web apps for TMB.

For a list of best practices mitigating the danger of client-side token storage, read the IETF's Best Current Practice for OAuth 2.0 Security, or this article summarizing OAuth 2.0 Best Practices for Developers.

TMB with DPoP#

One relatively new technology makes client-side tokens a lot safer — Demonstrating Proof of Possession (DPoP), available as the IETF RFC 9449.

Before DPoP, if an attacker got their hands on your OAuth access token, they could use it to make requests just like you. With DPoP, the token alone isn't sufficient; the client must also prove their identity with a cryptographic signature.

DPoP works by binding the token to a DPoP key, then requiring both the access token and a signature in requests. DPoP-enabled APIs reject any request that isn't signed by the DPoP key.

Your browser stores the DPoP key using a web cryptography API that prevents exfiltration. The browser can sign requests with the DPoP key, but it can't access the key itself.

An attacker that manages to insert malicious JavaScript into your browser could make calls using a token signed by the key. But the token is only useful when the attacker can sign requests with the DPoP key, which is only possible in your browser. So we end up with a risk profile equivalent to BFF:

BFF == TMB with DPoP > TMB > BBOC

FusionAuth added support for DPoP in version 1.63.0. For a great visual walkthrough of the protocol, see the interactive DPoP site.

When to use TMB#

Since TMB is much less secure than BFF, there are few reasons to choose TMB. Below are three:

Latency#

By...