Internet DRAFT - draft-burgin-jenkins-identity-chaining
draft-burgin-jenkins-identity-chaining
OAuth Working Group M. Jenkins
Internet-Draft National Security Agency
Intended status: Standards Track K. Burgin
Expires: 12 May 2023 8 November 2022
OAuth Identity Chaining
draft-burgin-jenkins-identity-chaining-00
Abstract
This specification defines a new OAuth claim that allows a proxying
OAuth client to pass identity information for a different OAuth
client to an OAuth authorization server during a token request. The
authorization server uses this additional identity information when
populating the "client_id" and "cnf" fields of the returned access
token instead of the identity information about the proxying client
requesting the token.
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 12 May 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jenkins & Burgin Expires 12 May 2023 [Page 1]
Internet-Draft OAuth Identity Chaining November 2022
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2
2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. "chained_id" Claim . . . . . . . . . . . . . . . . . . . . . 4
4. Non-normative Example . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The Mutual TLS Profile for OAuth 2.0 specification [RFC8705] states
that when a client authenticates to the token endpoint of an
authorization server using mTLS, the confirmation ("cnf") claim in
the returned token is populated with the SHA-256 thumbprint of the
client's X.509 certificate when the authorization server issues
sender constrained tokens.
This document defines a new OAuth claim, "chained_id", that allows a
client to pass the "client_id" and "cnf" values for a different OAuth
client in a token request. The authorization server uses the values
in the "chained_id" claim to populate the "client_id" and "cnf"
claims in the returned access token instead of those of the
requesting client.
1.1. Conventions and Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
Jenkins & Burgin Expires 12 May 2023 [Page 2]
Internet-Draft OAuth Identity Chaining November 2022
This specification uses the terms "Access Token", "Authorization
Server", "Client", "Protected Resource", "Resource Server", and
"Token Endpoint" defined by OAuth 2.0 [RFC6749], the term "Assertion"
defined by [RFC7521], the term "Token Endpoint" defined by [RFC7662],
the term "Token Exchange" defined by [RFC8693], and the terms defined
by OpenID Connect Core 1.0 [OIDC-Core].
2. Use Case
The primary use case is a situation where a protected resource (PR1)
may need to call a second protected resource (PR2) in a different
ICAM ecosystem to satisfy a query received from a client. PR1 cannot
simply relay the token, Token 1, it received from the client to PR2
since PR2 trusts a different authorization server (AS2). Also, when
PR1 presents its token to PR2, we want PR2 to be able to make
authorization decisions based on PR1's identity as asserted by the
"client_id" and "cnf" fields in the token.
Before presenting the proposed solution, we state some assumptions
used in this use case. The first is that OAuth clients authenticate
to authorization servers using mTLS which allows the authorization
servers to sender constrain tokens by populating a "cnf" field in
issued tokens. The second is that protected resources make
authorization decisions based upon certain claims that identify the
client presenting the token.
The method proposed in this specification that enables PR1 to obtain
a sender constrained token that contains PR1 identity information
necessary for authorization decisions at PR2 is as follows and is
shown in Figure 1.
PR1 performs token exchange with its authorization server (AS1) to
exchange Token 1 for a second token, Token 2, that is valid at PR2
and contains the identity information for PR1.
However, when AS1 receives the token exchange request from PR1, AS1
does not generate the token, Token 2, that is returned to PR1 to
complete the token exchange request. Instead, AS1 generates a JWT
assertion and, acting as an OAuth client, issues an assertion grant
request to AS2 using the generated JWT assertion. AS2 then generates
Token 2, returns it to AS1 to complete the assertion grant request,
and AS1 returns Token 2 to PR1 to complete the token exchange
request.
Jenkins & Burgin Expires 12 May 2023 [Page 3]
Internet-Draft OAuth Identity Chaining November 2022
Under normal circumstances, AS2 will populate the "client_id" and
"cnf" fields with the values for AS1 since it, acting as an OAuth
client, issued the assertion grant request to AS2. We define a new
OAuth parameter in the next section to allow AS2 to populate these
fields with the values for PR1 so Token 2 will pass the authorization
checks at PR2.
Org 1 Org 2
+------+ +---+ +---+
| | | |-----(7)-Token 2----->| |
|Client|-(1)-Token 1->|PR1| |PR2|
| | | | | |
+------+ +---+ +---+
| ^
(2) Token Exchange | |
Request | |
| | (6) Return
| | Token 2
v |
+---+ +---+
(3) Generate | |--(4)-JWT Assertion-->| |
JWT Assertion |AS1| Grant Request |AS2|
| |<-----(5)-Token 2-----| |
+---+ +---+
Figure 1: Token Exchange Protocol Flow when AS2 Generates Token 2
3. "chained_id" Claim
The "chained_id" claim value in a token request is a JSON object that
contains claims about an OAuth client that is different from a
proxying OAuth client making the token request. For the use case
described in Section 2, the requesting client (AS1) includes the
"client_id" and "cnf" claims of a different client (PR1) in a
"chained_id" claim in the request. If the proxying client (AS1)
making the request is registered with the authorization server (AS2),
the authorization server (AS2) populates the "client_id" and "cnf"
claims in the returned access token with the values in the
"chained_id" claim in the request (those identifying PR1) instead of
those of the proxying client making the request (AS1).
Jenkins & Burgin Expires 12 May 2023 [Page 4]
Internet-Draft OAuth Identity Chaining November 2022
4. Non-normative Example
The following is a non-normative example using the example in
Section 2 Where AS1 makes an assertion grant request to AS2 on behalf
of PR1. In the example,
"A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0" is the hash of PR1's
X.509 certificate.
When AS1 receives a token exchange request from PR1, it generates a
JWT assertion that includes a "chained_id" claim that identifies PR1
in the "client_id" and "cnf" sub-claims.
{
"sub": "user@example.com",
"aud": "https://as2.example2.com",
"iss": "https://as1.example1.com",
"chained_id": {
"client_id": "https://pr1.example1.com",
"cnf":{
"x5t#S256": "A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0"
}
}
}
Figure 2: Example JWT Assertion Using the chained_id claim
When AS2 receives the assertion grant request from AS1, it populates
the fields of a token that includes PR1's values in the "client_id"
and "cnf" fields and returns the token to AS1.
{
"sub":"user@example.com"
"aud":"https://pr2.example2.com"
"iss":"https://as2.example2.com"
"client_id: "https://pr1.example1.com"
"cnf":{
"x5t#S256":"A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0"
}
}
Figure 3: Token returned by AS2 to AS1 for PR1
AS1 returns the token to PR1 to complete the token exchange request.
Jenkins & Burgin Expires 12 May 2023 [Page 5]
Internet-Draft OAuth Identity Chaining November 2022
5. Security Considerations
To ensure the proxying OAuth client requesting the second token (AS1)
is trusted by the authorization server generating the second token
(AS2) to make token requests that include a "chained_id" claim, we
assume that AS1 has a pre-existing trust relationship with AS2.
6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
"Assertion Framework for OAuth 2.0 Client Authentication
and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521,
May 2015, <https://www.rfc-editor.org/info/rfc7521>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/info/rfc7662>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/info/rfc8693>.
[RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T.
Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
and Certificate-Bound Access Tokens", RFC 8705,
DOI 10.17487/RFC8705, February 2020,
<https://www.rfc-editor.org/info/rfc8705>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
2021, <https://www.rfc-editor.org/info/rfc9068>.
Jenkins & Burgin Expires 12 May 2023 [Page 6]
Internet-Draft OAuth Identity Chaining November 2022
[OIDC-Core]
OpenID_Foundation, "OpenID Connect Core 1.0 incorporating
errata set 1", 10 November 2014.
Authors' Addresses
Mike Jenkins
National Security Agency
Email: mjjenki@cyber.nsa.gov
Kelley Burgin
Email: kelley.burgin@gmail.com
Jenkins & Burgin Expires 12 May 2023 [Page 7]
