IMO this is highlighting a previous poor security practice. Passing bearer tokens to backend services as a convenient way to share security context just increases the risk of those tokens being exposed. You wouldn’t do it with user passwords, so you shouldn’t be doing it with access tokens either.
In reality the downstream services have to trust the upstream gateway/service that initially validates the token. (After all, it can simply store all the bearer tokens it sees and use them to make whatever downstream API calls it likes). So surface that trust in your design: have the downstream services consume the security context information in a form that makes it clear that it comes from the gateway *not* directly from a user/client. One approach is what is sometimes called the Phantom Token Pattern, whereby the “real” token on the incoming call is replaced by a short-lived JWT issued by the gateway service itself. Or you can just pass the data as JSON or some other format if you already trust the backend connections. — Neil > On 16 Oct 2025, at 20:57, Yaron ZEHAVI <[email protected]> > wrote: > > > Hello, > I’m sharing a dilemma we’re having, which I’ve shared with the authors of rfc > 9449 and got initial feedback, as it goes beyond the scope of the rfc. > > While starting to use DPoP tokens (validated by internet facing backends), we > weren’t sure how to handle calling downstream resource servers. > > In the Bearer token Paradigm, we were forwarding access tokens to downstream > resource servers (within the same security domain), to share the security > context (who's the client, the actor, the entitlements). > However, forwarding a DPoP token is bound to break as the htu claim cannot > match downstream endpoints. > Sending DPoP tokens as Bearer tokens is explicitly handled by the rfc as a > potential downgrade attack that should be rejected. > > So what can be done? > While it is possible to use token exchange profiles or the txn-token draft, > so a resource server could exchange the DPoP token for a bearer token (or a > DPoP token bound to itself), this seems like adding complexity without much > benefit. > > We're leaning towards forwarding both DPoP tokens + Proofs, to be validated > downstream following DPoP’s validation rules, with the exception of the htu > (and sometimes htm) claims, whose validation rules shall depend on the > resource server’s role: > Never a downstream resource server (serving external internet traffic) - > Strict DPoP htu claim enforcement > Sometimes serving external internet traffic and other times a downstream > resource server - Strict DPoP htu claim enforcement, except for allowList of > permitted upstream resource servers domains > Always a downstream resource server - Lax DPoP htu claim enforcement > > <image001.png> > > Looking forward for feedback and thoughts. > > Regards, > Yaron ZEHAVI > > This message and any attachment ("the Message") are confidential. If you have > received the Message in error, please notify the sender immediately and > delete the Message from your system, any use of the Message is forbidden. > Correspondence via e-mail is primarily for information purposes. RBI neither > makes nor accepts legally binding statements via e-mail unless explicitly > agreed otherwise. Information pursuant to § 14 Austrian Companies Code: > Raiffeisen Bank International AG; Registered Office: Am Stadtpark 9, 1030 > Vienna, Austria; Company Register Number: FN 122119m at the Commercial Court > of Vienna (Handelsgericht Wien). > Classification: GENERAL > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
