Thanks for your prompt feedback Neil, It’s very interesting that we come to quite different conclusions.
Perhaps I should note, that in our case access tokens are relatively short lived, so amassing them wouldn’t provide a malicious actor much value. We see forwarding tokens favorably because for us it boils down to, who can a downstream resource server trust? We place higher trust in tokens issued by authorization servers and require validation on every layer, rather than delegating authority to application layers to issue phantom tokens and then trusting that these upstream components have done their job properly and have not been compromised. With Phantom tokens I suppose we’d be concerned of a compromised application component (risk grows when facing the internet), misused to issue phantom tokens with malicious content, or just not validating tokens correctly. Yaron Classification: GENERAL From: Neil Madden <[email protected]> Sent: Thursday, October 16, 2025 10:23 PM To: Yaron ZEHAVI <[email protected]> Cc: [email protected]; Grese HYSENI <[email protected]>; Henrik KROLL <[email protected]> Subject: Re: [OAUTH-WG] DPoP tokens vs downstream resource servers You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> This message is from an external sender - be cautious, particularly with links and attachments. 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]<mailto:[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: 1. Never a downstream resource server (serving external internet traffic) - Strict DPoP htu claim enforcement 2. 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 3. 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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> 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).
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
