[OAUTH-WG] Re: DPoP tokens vs downstream resource servers

Neil Madden Sat, 18 Oct 2025 11:17:36 -0700

I think that risk is pretty minor. Use eg Tink’s JWT library backed with a KMS. Almost all the risks of JWTs are validation-side not issuer-side.

On 16 Oct 2025, at 23:45, Lombardo, Jeff <[email protected]> wrote:

You want people to run their own ~~crypto~~ JWT issuance logic at the Gateway?

The general reason of using / talking to an AS is:

To not have to write any code in my gateway to issue / mint tokens in the first place and rely on rubberstamped and secure implementation
To not have to expose at the Gateway level, the keys and other elements myself

I am not sure on how much what you are proposing is solving risks and not opening new ones.

Jean-François “Jeff” Lombardo | Amazon Web Services

Architecte Principal de Solutions, Spécialiste de Sécurité
Principal Solution Architect, Security Specialist
Montréal, Canada

Commentaires à propos de notre échange? Exprimez-vous ici.

Thoughts on our interaction? Provide feedback here.

From: Neil Madden <[email protected]>
Sent: October 16, 2025 3:09 PM
To: Lombardo, Jeff <[email protected]>
Cc: Yaron ZEHAVI <[email protected]>; [email protected]; Grese HYSENI <[email protected]>; Henrik KROLL <[email protected]>; Lombardo, Jeff <[email protected]>
Subject: RE: [EXT] [OAUTH-WG] Re: DPoP tokens vs downstream resource servers

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque.

You Don’t Need Token Exchange (YDNTE?), just have the gateway directly issue a JWT. And you don’t need DPoP on those backend calls (the JWT the gateway issues should already be as constrained as a DPoP proof).

On 16 Oct 2025, at 22:39, Lombardo, Jeff <[email protected]> wrote:

Still, even with the Phantom Token (a Curity pattern / construct), this leads to a Token Exchange at the edge. Meaning that the inbound DPoP bound Token should be exchanged as actor token for a new minted token scoped for downstream.

Still the Edge component cannot generate a new proof for this actor (DPoP bound token) to use with the token exchange request so could, theorycally , not be able to receive the new minted token scoped for downstream.

Jean-François “Jeff” Lombardo | Amazon Web Services

Architecte Principal de Solutions, Spécialiste de Sécurité
Principal Solution Architect, Security Specialist
Montréal, Canada

Commentaires à propos de notre échange? Exprimez-vous ici.

Thoughts on our interaction? Provide feedback here.

From: Neil Madden <[email protected]>
Sent: October 16, 2025 2:26 PM
To: Yaron ZEHAVI <[email protected]>
Cc: [email protected]; Grese HYSENI <[email protected]>; Henrik KROLL <[email protected]>
Subject: [EXT] [OAUTH-WG] Re: DPoP tokens vs downstream resource servers

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque.

I recommend doing some proper threat modelling of your architecture. Having backend services only trust tokens from the AS only prevents spoofing and tampering of the data directly in that token. It fails to guarantee that the token relates to the backend API requests being made, fails to guarantee that those requests actually relate to anything the user actually requested, fail to guarantee that user requests actually make it to backend services, etc etc. When you properly model these threats you’ll see that in fact backend services put enormous trust in the edge/gateway services in any case.

I would suggest implementing the phantom token pattern in a hardened API gateway, which you treat as rigorously as you do the AS (which is after all also a frontline service). The gateway can then enrich the phantom token with elements of the request context that make sense to backend services - eg idempotency/transaction id. This is much more effective at preventing a broad range of threats, and it doesn’t spray high-privilege bearer tokens across your estate. The gateway provides complete mediation and enforces least privilege on downstream requests.

— Neil

On 16 Oct 2025, at 21:42, Yaron ZEHAVI <[email protected]> wrote:

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]. Learn why this is important

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]> 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]

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]

[OAUTH-WG] Re: DPoP tokens vs downstream resource servers

Reply via email to