[OAUTH-WG] Re: New Draft: OAuth 2.0 External Assertion Authorization Grant

["Lombardo, Jeff" <[e-mail]>]

Hi,

That was an interesting read thanks. I have few questions:


  *   When you said that:


- In the jwt-bearer grant, the client presents a JWT it has signed, and the Authorization Server validates it using a public key that has been pre-registered or exchanged.
- In the external-assertion grant, the JWT is issued by an external entity the AS already trusts (for example, a federated IdP). The AS validates it using that IdP's keys and trust configuration, not a per-client key exchange.

It is not completely accurate against the latest of the Drafts that exist and are evaluated already by the working group, see https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/. In this Draft - Figure 1, from my understanding, the authorization grant JWTis issued by a trusted 3rd party AS (domain A) to be used at the AS (domain B). This is highlighted in section 2.1 / (C):

This requires a trust relationship between the authorization servers in trust domain A and trust domain B (sometimes called federation, such a trust relationship typically manifests in the exchange of key material where domain B's authorization server trusts the public key(s) of domain A to sign JWT authorization grants).

What would be the differences with the proposal here (introduction of a new grant type excluded)?


  *   I fully noted the:


If the request is valid and authorized, the AS issues an access token per Section 5.1 of [RFC6749]. A refresh token MUST NOT be issued for this grant type.


                But could this be worked out within  https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/ directly?

Jeff

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<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.

Thoughts on our interaction? Provide feedback here<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.

From: Jorge Turrado Ferrero <[e-mail]>
Sent: October 3, 2025 8:28 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: [EXT] [OAUTH-WG] New Draft: OAuth 2.0 External Assertion Authorization Grant


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.

Hello,

We submitted https://datatracker.ietf.org/doc/draft-external-assertion-oauth-grant/

This draft introduces a new OAuth 2.0 authorization grant type, "urn:ietf:params:oauth:grant-type:external-assertion", that allows a client to obtain an access token from an Authorization Server by presenting a verifiable assertion issued by a trusted external Identity Provider.

The motivation is to support zero trust architectures in cloud and server farm environments, where workloads and applications often authenticate with different identity providers but must access shared resources under a common  authorization server. Today, each deployment implements its own bespoke token exchange or local credential system, leading to fragmented approaches and operational overhead.

The External Assertion Grant standardizes this flow so that:

- Workloads can present a JWT assertion from a trusted external IdP.
- Authorization Servers can validate and transform it into a  short-lived access token.
- Access can be consistently enforced without long-lived secrets or  provider-specific hacks.

A key difference from the existing "urn:ietf:params:oauth:grant-type:jwt-bearer" grant is the trust model:
- In the jwt-bearer grant, the client presents a JWT it has signed, and the Authorization Server validates it using a public key that has been pre-registered or exchanged.
- In the external-assertion grant, the JWT is issued by an external entity the AS already trusts (for example, a federated IdP). The AS validates it using that IdP's keys and trust configuration, not a per-client key exchange.

This enables practical zero trust at scale: every request is authenticated and authorized based on verifiable, short-lived identity tokens, even when crossing trust boundaries between providers.

Feedback from the WG is very welcome on scope, validation requirements, and applicability to real-world multi-cloud and server farm scenarios.