OAuth 2.0 External Assertion Authorization Grant

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 30 March 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Conventions and Definitions

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 ([RFC2119], [RFC8174]) when, and only when, they appear in all capitals, as shown here.¶

Authorization Server (AS):

The OAuth 2.0 server that issues access tokens.¶

External Identity Provider (External IdP):

An OAuth 2.0/OpenID Connect compliant identity provider that issues JWT assertions trusted by the AS.¶

Assertion:

A signed JWT bearing claims used by the AS to authenticate and authorize the client for token issuance.¶

2. Introduction

The OAuth 2.0 Authorization Framework ([RFC6749]) defines multiple grant types for obtaining access tokens. In many environments, workloads already possess identities issued by an external IdP. In order to interact with a resource server that relies on an AS different from the external IdP, a mechanism is needed to exchange the external identity for a locally-issued access token without provisioning long-lived secrets.¶

This document defines the "external assertion" grant type, identified by urn:ietf:params:oauth:grant-type:external-assertion, which allows a client to present a verifiable JWT assertion issued by a trusted external IdP to an AS in exchange for a short-lived access token. The grant is conceptually similar to token exchange ([RFC8693]) but is narrowly focused on a client-submitted external JWT assertion used as an authorization grant, and it does not define subject or actor token semantics beyond the validation rules herein.¶

3. Protocol Overview

At a high level, the client obtains a JWT assertion from an external IdP and submits it to the AS's token endpoint using the grant type defined in this document. The AS validates the assertion according to its local trust configuration (e.g., trusted issuers and keys), and, if validation succeeds and policy permits, issues an access token to the client.¶

4. External Assertion Grant Type

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:external-assertion&
client_id=s6BhdRkqt3&
client_assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "token_type": "bearer",
  "expires_in": 3600
}

5. Security Considerations

The security of this grant depends on the AS's trust configuration and assertion validation. Deployments MUST:¶

• Restrict trusted issuers and acceptable algorithms by policy.¶

• Validate signatures and enforce exp/nbf strictly.¶

• Bind assertions to the AS via aud; reject generic or missing audiences.¶

• Prevent replay via unique jti and server-side caching within validity windows.¶

• Issue short-lived access tokens and prefer least-privilege scopes.¶

• Use TLS for all endpoints and key retrieval.¶

• Log validation outcomes and consider rate limiting failed attempts.¶

If the AS includes an "actor" representation in issued tokens (e.g., the act claim from [RFC8693]), it SHOULD ensure that privacy and policy constraints are respected.¶

6. Privacy Considerations

Assertions may include identifiers that can correlate clients across services. Deployments SHOULD minimize personally identifiable information in assertions, avoid unnecessary claim propagation into issued tokens, and follow data minimization practices.¶

7. IANA Considerations

This document requests registration of the following value in the "OAuth URI" registry:¶

URN: urn:ietf:params:oauth:grant-type:external-assertion
Common Name: External Assertion Grant
Change Controller: IESG
Specification Document: This document

Appendix A. Acknowledgments

The authors thank the OAuth community for prior work on assertion-based flows and token exchange.¶

Authors' Addresses