Propagating the initial token could allow it to be replayed by a downstream service

[william-tran]

In the presentation, I talk about how at the conclusion of an authcode flow for a confidential client (eg a server-side webapp), the webapp stores the token in session, and the session is now authenticated. The browser never sees the token, the browser just has a session cookie. If this webapp can only be invoked via an authenticated session (ie this session cookie), this is good, because the session cookie is never propagated, and is the only thing that can be used to invoke the webapp as that user.

Now lets say we're using the implicit grant from a JS SPA. The server side web-app is just a resource server, or a facade for other APIs, ie a BFF. This front door is now directly invokable by the token that the SPA got. If this token were to be propagated as the initial token, downstream services could act as the user by making requests against the front door.

The responsibilities of the front door (BFF, gateway, whatever you want to call it) need to be clear, in that the thing used to invoke it (the token or session cookie) cannot be propagated downstream. If only session cookie were used there's nothing more to do, but in the case of a token, we would need to propagate just the token's claims, and not the entire token. Downstream apps would then need to trust the front door enough to trust the claims its making about the user. An ID token could be propagated if available, as long as the ID token isn't usable on its own against the front door.