Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt

From: [email-masked]
Date: Sun, 21 Jul 2019 05:55:24 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
        Author          : Vittorio Bertocci
	Filename        : draft-ietf-oauth-access-token-jwt-01.txt
	Pages           : 15
	Date            : 2019-07-20

Abstract:
   This specification defines a profile for issuing OAuth2 access tokens
   in JSON web token (JWT) format.  Authorization servers and resource
   servers from different vendors can leverage this profile to issue and
   consume access tokens in interoperable manner.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-01
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 22 Jul 2019 16:01:38 +0200

Hi Vittorio,

thanks for contributing this specification. It fills a further gap in the OAuth universe :-)

Here are my comments:

- 2.2.1 there are other sources for identity claims, e.g. https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html. 

I recommend to open the clause

"Any additional attributes whose semantic is well described by the
   attributes description found in section 5.1 of [
OpenID.Core] SHOULD
   be codified in JWT access tokens via the corresponding claim names in
   that section of the OpenID Connect specification.  The same holds for
   attributes defined in [RFC7662]."

by adding 

"and other identity related specifications.” 

Alternatively, the draft could also refer to the IANA “OAuth Token Introspection Response” registry as source for JWT claims.

- 2.2.2. 

"If an authorization request includes a scope parameter, the
   corresponding issued JWT access token MUST include a scope claim as
   defined in section 4.2 of [TokenExchange]."

Why do you establish such a strong link between the scope in the authorization request and the access token? I’m aware of implementations that map scope values to audience values and therefore do not carry the scope value to the resource server. I suggest to soften this requirement and make it a recommendation. 

- 5. 

"The JWT access token data layout described here is very similar to the one of the id_token as defined by [OpenID.Core].  Without the
   explicit typing required in this profile, in line with the recommendations in [JWT.BestPractices] there would be the risk of
   attackers using JWT access tokens in lieu of id_tokens."

I like this practice but it is not established yet in the OpenID Connect universe. This means any OIDC RP will process an access token because it will just ignore the type header. 

draft-ietf-oauth-jwt-introspection-response therefore gives recommendation on how to use iss and aud claim to prevent JWT abuse (https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-04#section-6.1). 

Mapping this pattern to JWTs as access token requires that there must not be the same aud value for a resource server and any other JWT consumer, e.g. an OpenID Connect RP. 

kind regards,
Torsten. 

> On 21. Jul 2019, at 14:55, [email-masked] wrote:
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 22 Jul 2019 08:13:11 -0700

Thank you Torsten for the prompt review and insightful comments!

2.2.1 - excellent point. I added the suggested language.

2.2.2 - interesting. I did think of cases similar to profile in OIDC, where
the effect of the request is influencing the layout of the resulting
idtoken, but concluded that it didn't apply as is for access tokens. Given
that you have direct knowledge of such cases in the wild, I am happy to
relax the MUST into a SHOULD.

5. - this is going to be problematic in the wild. For example, in the azure
AD world a registered application can play both the role of an API and a
client; and requests for tokens targeting the app can use any identifier
assigned to the app. That means that although idtokens will only be issued
if the request identifies the client via clientID, access tokens requests
for it will be honored (and reflected in aud) both in the case the resource
parameter contains the clientID or the API URI of the target application.
In fact I suspect that the most recent version of the service uses the
clientID as preferred identifier, if not the only one. Mike/Tony can
confirm or deny.
As a compromise, we could add language in the spec that recommends the use
of a unique audience when viable, as an extra measure in case the typ value
isn't honored. WDYT?

On Mon, Jul 22, 2019 at 7:01 AM Torsten Lodderstedt <[email-masked]>
wrote:

> - 2.2.1 there are other sources for identity claims, e.g.
> https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html.
>
> Alternatively, the draft could also refer to the IANA “OAuth Token
> Introspection Response” registry as source for JWT claims.
>
> - 2.2.2.
>
> Why do you establish such a strong link between the scope in the
> authorization request and the access token? I’m aware of implementations
> that map scope values to audience values and therefore do not carry the
> scope value to the resource server. I suggest to soften this requirement
> and make it a recommendation.
>
> - 5.
>
> "The JWT access token data layout described here is very similar to the
> one of the id_token as defined by [OpenID.Core].  Without the
>    explicit typing required in this profile, in line with the
> recommendations in [JWT.BestPractices] there would be the risk of
> I like this practice but it is not established yet in the OpenID Connect
> universe. This means any OIDC RP will process an access token because it
> will just ignore the type header.
>
> draft-ietf-oauth-jwt-introspection-response therefore gives recommendation
> on how to use iss and aud claim to prevent JWT abuse (
> https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-04#section-6.1).
>
>
> Mapping this pattern to JWTs as access token requires that there must not
> be the same aud value for a resource server and any other JWT consumer,
> e.g. an OpenID Connect RP.
>
> kind regards,
> Torsten.
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 22 Jul 2019 18:25:57 +0200

> On 22. Jul 2019, at 17:13, Vittorio Bertocci <[email-masked]> wrote:
> 
> 2.2.2 - interesting. I did think of cases similar to profile in OIDC, where the effect of the request is influencing the layout of the resulting idtoken, but concluded that it didn't apply as is for access tokens. Given that you have direct knowledge of such cases in the wild, I am happy to relax the MUST into a SHOULD.
> 
> 5. - this is going to be problematic in the wild. For example, in the azure AD world a registered application can play both the role of an API and a client; and requests for tokens targeting the app can use any identifier assigned to the app. That means that although idtokens will only be issued if the request identifies the client via clientID, access tokens requests for it will be honored (and reflected in aud) both in the case the resource parameter contains the clientID or the API URI of the target application.

Interesting and (in my opinion) reasonable. Out of the top of my head I don’t see how this has a negative security impact since the recipient is always the same service. 

> In fact I suspect that the most recent version of the service uses the clientID as preferred identifier, if not the only one. Mike/Tony can confirm or deny.
> As a compromise, we could add language in the spec that recommends the use of a unique audience when viable, as an extra measure in case the typ value isn't honored. WDYT?

Having a unique audiences at least for different services is key.

In fact, I’m concerned about JWT confusion in OIDC RPs in the wild that do generally not honor the type (as long as we do not update OIDC Core to require this and it is being adopted). I think since your draft requires both, iss and aud to be present, this threat is being dealt with. Additionally stating that unique audiences shall be used for different services should be ok.

>  
> 
> On Mon, Jul 22, 2019 at 7:01 AM Torsten Lodderstedt <[email-masked]> wrote:
> Hi Vittorio,
>

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 22 Jul 2019 12:32:56 -0700

> Additionally stating that unique audiences shall be used for different
services should be ok.
Fair! I'll add language to that effect in section 5 and update the draft
before Friday.
thanks!
V.

On Mon, Jul 22, 2019 at 9:25 AM Torsten Lodderstedt <[email-masked]>
wrote:

> > 2.2.2 - interesting. I did think of cases similar to profile in OIDC,
> where the effect of the request is influencing the layout of the resulting
> > 5. - this is going to be problematic in the wild. For example, in the
> azure AD world a registered application can play both the role of an API
> and a client; and requests for tokens targeting the app can use any
> identifier assigned to the app. That means that although idtokens will only
> be issued if the request identifies the client via clientID, access tokens
> requests for it will be honored (and reflected in aud) both in the case the
> resource parameter contains the clientID or the API URI of the target
> application.
>
> Interesting and (in my opinion) reasonable. Out of the top of my head I
> don’t see how this has a negative security impact since the recipient is
> always the same service.
>
> > As a compromise, we could add language in the spec that recommends the
> use of a unique audience when viable, as an extra measure in case the typ
> value isn't honored. WDYT?
>
> In fact, I’m concerned about JWT confusion in OIDC RPs in the wild that do
> generally not honor the type (as long as we do not update OIDC Core to
> require this and it is being adopted). I think since your draft requires
> both, iss and aud to be present, this threat is being dealt with.
> Additionally stating that unique audiences shall be used for different
> services should be ok.
>
>
> >
> >
> > draft-ietf-oauth-jwt-introspection-response therefore gives
> recommendation on how to use iss and aud claim to prevent JWT abuse (
> > Mapping this pattern to JWTs as access token requires that there must
> not be the same aud value for a resource server and any other JWT consumer,

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 23 Jul 2019 07:02:58 +0200

thanks 

> Am 22.07.2019 um 21:32 schrieb Vittorio Bertocci <[email-masked]>:
> 
> > Additionally stating that unique audiences shall be used for different services should be ok.
> Fair! I'll add language to that effect in section 5 and update the draft before Friday.
> thanks!
> V. 
> 
>> On Mon, Jul 22, 2019 at 9:25 AM Torsten Lodderstedt <[email-masked]> wrote:
>> 
>>

---

From: Petteri Stenius <[email-masked]>
Date: Wed, 24 Jul 2019 14:00:04 +0000

Hi Vittorio,

Thanks for working on this. I think this will be valuable. I have a couple of comments.

About relationship of this draft with token exchange, introspection and revocation:

Should there be a distinct Token Type Identifier defined for JWT Access Token, to enable exchange of reference type access token and value type access token? I'm thinking of a use case where I want authorization code flow to return an opaque reference token and I want my backend services to exchange this into a value token, to avoid further introspection on the backend side.

Introspection (and userinfo) with JWT Access Token should work as expected. If a JWT Access Token is revoked then introspection response should become negative. Is it reasonable to add text that advises the resource server to invoke introspection if it wants to make sure the token has not been revoked?

Thanks,
Petteri

-----Original Message-----
From: OAuth <[email-masked]> On Behalf Of [email-masked]
Sent: sunnuntai 21. heinäkuuta 2019 15.55
To: [email-masked]
Cc: [email-masked]
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

---

From: Vittorio Bertocci <[email-masked]>
Date: Wed, 24 Jul 2019 08:18:46 -0700

Hi Petteri,
thanks for your comments!
Re: indicator in resource indicator
One of the big goals of the profile is to promote interoperability, but
ultimately the choice of what style should be used to represent ATs falls
on each AS. In my experience most AS instances choose one style (opaque or
JWT) and stick with that rather than offering a choice, hence although I
see how adding an explicit reference to the desired style would make the
client feel empowered on the matter, in practice it would not make much of
a difference. The client can find out from the AS documentation what
particular choice that AS made.
A further consideration: the AT style is largely a matter between the AS
and the RS, given that it is the latter that needs to worry about how to
validate incoming ATs- hence the requestor (the client) should't probably
have much say about the matter. What if the API only knows how to validate
JWT ATs but the client selects opaque?

On introspection: let me think a bit more about it. One of the reasons for
which various AS instances issue AT as JWT is to avoid
implementing/exposing an introspection endpoint. The consideration about
revocation is valid IMO, but I am not sure if imposing use of introspection
would fly in practice.

thanks
V.

On Wed, Jul 24, 2019 at 7:00 AM Petteri Stenius <
[email-masked]> wrote:

> Should there be a distinct Token Type Identifier defined for JWT Access
> Token, to enable exchange of reference type access token and value type
> access token? I'm thinking of a use case where I want authorization code
> flow to return an opaque reference token and I want my backend services to
> exchange this into a value token, to avoid further introspection on the
> backend side.
>
> Introspection (and userinfo) with JWT Access Token should work as
> expected. If a JWT Access Token is revoked then introspection response
> should become negative. Is it reasonable to add text that advises the
> resource server to invoke introspection if it wants to make sure the token
> has not been revoked?
>
>
> Thanks,
> Petteri
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>