Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Kelley] add sender constraints #90

Closed
wants to merge 3 commits into from
Closed

[Kelley] add sender constraints #90

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
43fc5d6
[Kelley] add sender constraints
arndt-s Jul 4, 2024
ecbbb7f
remove duplicated sentence and trailing whitespaces
arndt-s Jul 8, 2024
565530b
remove remaining trailing whitespace
arndt-s Jul 8, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 29 additions & 10 deletions draft-ietf-oauth-identity-chaining.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ title: OAuth Identity and Authorization Chaining Across Domains
abbrev:
lang: en
kw: []
# date: 2022-02-02 -- date is filled in automatically by xml2rfc if not given
# date: 2024-07-01 -- date is filled in automatically by xml2rfc if not given
author:
- name: Arndt Schwenkschuster
org: Microsoft
Expand Down Expand Up @@ -46,9 +46,10 @@ normative:
RFC6749: # OAuth 2.0 Authorization Framework
RFC8693: # OAuth 2.0 Token Exchange
RFC7523: # JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
RFC8705: # mTLS
RFC8707: # Resource Indicators for OAuth 2.0
RFC8414: # OAuth 2.0 Authorization Server Metadata

RFC9449: # DPoP
informative:

I-D.ietf-oauth-selective-disclosure-jwt:
Expand Down Expand Up @@ -77,7 +78,7 @@ A client in trust domain A that needs to access a resource server in trust domai

## Overview

The identity and authorization chaining flow outlined below describes how a combination of OAuth 2.0 Token Exchange {{RFC8693}} and JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants {{RFC7523}} are used to address the use cases identified. The appendix include two additional examples that describe how this flow is used. In one example, the resource server acts as the client and in the other, the authorization server acts as the client.
The identity and authorization chaining flow outlined below describes how a combination of OAuth 2.0 Token Exchange {{RFC8693}} and JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants {{RFC7523}} are used to address the use cases identified. Section [Examples](#examples) includes two additional examples that describe how this flow is used. In one example, the resource server acts as the client and in the other, the authorization server acts as the client.

~~~~
+-------------+ +-------------+ +---------+
Expand Down Expand Up @@ -131,8 +132,15 @@ The flow illustrated in Figure 1 shows the steps the client in trust Domain A ne
* (F) The client now possesses an access token to access the protected resource in Domain B.

## Authorization Server Discovery

This specification does not define authorization server discovery. A client MAY maintain a static mapping or use other means to identify the authorization server. The `authorization_servers` property in {{I-D.ietf-oauth-resource-metadata}} MAY be used.

## Sender Constrained Tokens

The authorization server MAY issue sender constrained tokens. There are currently two options for sender constrained tokens: Mutually Authenticated TLS (mTLS) {{RFC8705}} and Demonstrating Proof of Possessions (DPoP) {{RFC9449}}.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this in regards to authorization server in Domain A or B or both?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both


Additionally, there are two examples of identity and authorization chaining: resource server acting as the client and the authorization server acting as the client. Additional details of the examples are in [Examples](#examples).
arndt-s marked this conversation as resolved.
Show resolved Hide resolved

## Token Exchange

The client performs token exchange as defined in {{RFC8693}} with the authorization server for its own domain (e.g., Domain A) in order to obtain a JWT authorization grant that can be used with the authorization server of a different domain (e.g., Domain B) as specified in section 1.3 of {{RFC6749}}.
Expand All @@ -142,19 +150,23 @@ The client performs token exchange as defined in {{RFC8693}} with the authorizat
The parameters described in section 2.1 of {{RFC8693}} apply here with the following restrictions:

{:vspace}
scope
"scope"
: OPTIONAL. Additional scopes to indicate scopes included in the returned JWT authorization grant. See [Claims transcription](#claims-transcription).

resource
"resource"
: REQUIRED if audience is not set. URI of authorization server of targeting domain (domain B).

audience
"audience"
: REQUIRED if resource is not set. Well known/logical name of authorization server of targeting domain (domain B).

"chained_id"
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RFC8693 does not specify a chained_in parameter. Do I understand correctly that this is rather a claim within the JWT assertion used to transfer cnf information from Authorization Server in domain A to Authorization Server in domain B?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I invented "chained_id" to carry the "cnf" claim. And yes, you understand correctly

Copy link
Contributor

@bc-pi bc-pi Jul 8, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I don't understand. This is in a list of token request parameters but is supposed to be a JWT claim?

: REQUIRED if the authorization server issues sender constrained tokens. The chained_id claim contains as a sub-claim the "cnf" value from the inbound token that was presented during token exchange.

### Processing rules

* If the request itself is not valid or if the given resource or audience are unknown, or are unacceptable based on policy, the authorization server MUST deny the request.
* The authorization server MAY add, remove or change claims. See [Claims transcription](#claims-transcription).
* If the inbound token is sender constrained, the authorization server MUST check the binding on the inbound token.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this would preclude the RS acting as the client case


### Token Exchange Response

Expand All @@ -164,6 +176,8 @@ All of section 2.2 of {{RFC8693}} applies. In addition, the following applies to

* The "aud" claim included in the returned JWT authorization grant MAY identify multiple authorization servers, provided that trust relationships exist with them (e.g. through federation). It is RECOMMENDED that the "aud" claim is restricted to a single authorization server to prevent an authorization server in one domain from presenting the client's authorization grant to an authorization server in a different trust domain. For example, this will prevent the authorization server in Domain B from presenting the authorization grant it received from the client in Domain A to the authorization server for Domain C.

* If the authorization server issues sender constrained tokens, the authorization server MUST include the "cnf" sub-claim from the "chained_id" claim from the issued JWT assertion.

### Example

The example below shows the message invoked by the client in trust domain A to perform token exchange with the authorization server in domain A (https://as.a.org/auth) to receive a JWT authorization grant for the authorization server in trust domain B (https://as.b.org/auth).
Expand Down Expand Up @@ -206,16 +220,16 @@ The client presents the JWT authorization grant it received from the authorizati
The authorization grant is a JWT bearer token, which the client uses to request an access token as described in the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants {{RFC7523}}. For the purpose of this specification the following descriptions apply:

{:vspace}
grant_type
"grant_type"
: REQUIRED. As defined in Section 2.1 of {{RFC7523}} the value `urn:ietf:params:oauth:grant-type:jwt-bearer` indicates the request is a JWT bearer assertion authorization grant.

assertion
"assertion"
: REQUIRED. Authorization grant returned by the token exchange (`access_token` response).

scope
"scope"
: OPTIONAL.

The client MAY indicate the audience it is trying to access through the `scope` parameter or the `resource` parameter defined in {{RFC8707}}.
The client MAY indicate the audience it is trying to access through the "scope" parameter or the "resource" parameter defined in {{RFC8707}}.

### Processing rules

Expand All @@ -224,6 +238,7 @@ The authorization server MUST validate the JWT authorization grant as specified
* The "aud" claim MUST identify the Authorization Server as a valid intended audience of the assertion using either the token endpoint as described Section 3 {{RFC7523}} or the issuer identifier as defined in Section 2 of {{RFC8414}}.
* The authorization server SHOULD deny the request if it is not able to identify the subject.
* Due to policy the request MAY be denied (for instance if the federation from domain A is not allowed).
* If the authorization server issues sender constrained tokens, the authorization server MUST check the binding on inbound assertion of the Access Token Request. Additionally, the authorization server MUST verify the "cnf" claim.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this work if the resource server acts as a client? Thinking out loud:

T0: AS1 issues AT to Alice.
T1: Alice presents AT to R1. R1 needs to call R2 (in domain 2).
T2: performs token exchange to AS1 (fails as AT is bound).


### Access Token Response

Expand Down Expand Up @@ -434,6 +449,10 @@ The editors would like to thank Joe Jubinski, Justin Richer, Aaron Parecki and

\[\[ To be removed from the final specification ]]

-03

* add sender constrained tokens

-02

* remove recommendation to not use RFC8693's requested_token_type
Expand Down
Loading