Subject: [OAUTH-WG] JWT access tokens and the revocation endpoint

From: Andrii Deinega <[email-masked]>
Date: Fri, 2 Oct 2020 15:19:47 -0700

Hi WG,

https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-10 provides
the flowing about JWT access tokens

“resource servers can consume them directly for authorization or other
purposes without any further round trips to introspection ( [RFC7662]) or
userinfo [OpenID.Core]) endpoints.”

which is completely understandable. I do understand that the objective of
this document is to standardize the token which the AS shares with the RS
as it was discussed in other email threads.

Here is what I would like to get a better understanding of:
1. How should a response of the introspection endpoint look like if the RS
makes an attempt to introspect a JWT access token?
2. How should a response of the OpenID Connect userinfo endpoint look like
for a JWT access token?

I assume that it’s expected to have no difference compared to a regular
bearer token (given that a particular implementation of the AS provides
these endpoints). Does it sound right?

If so, what are we going to get if the RS or the client revokes a valid JWT
access token using the revocation endpoint (RFC 7009)?

Do you think there is a need to add more detailed information about these
scenarios in the document? This way, we could refer back to these sections
in the documentation in case any disputes around security-related topics
come up.

Thank you.

Regards,
Andrii

---

From: Nicolas Mora <[email-masked]>
Date: Sat, 3 Oct 2020 13:18:08 -0400

My 2 cents,

Le 20-10-02 à 18 h 19, Andrii Deinega a écrit :
> 1. How should a response of the introspection endpoint look like if the
> RS makes an attempt to introspect a JWT access token?

AFAIK, the RFC doesn't specify if the introspection should be different
between an opaque AT and a JWT AT, so my guess is the introspection
result shouldn't be different either.

> 2. How should a response of the OpenID Connect userinfo endpoint look
> like for a JWT access token?
>There should be no difference in userinfo response between an opaque AT
and a JWT AT.

The userinfo and the introspection endpoints have different goals, and I
don't expect the userinfo to return data based on the AT provided
(except to identify the sub it relates to). Instead, the userinfo must
return user claims based on the AS configuration and the claims requested.

> these endpoints). Does it sound right?
That's my opinion too, although I don't recall any specification talking
about it, so I guess it's a matter of implementation.

> If so, what are we going to get if the RS or the client revokes a valid
> JWT access token using the revocation endpoint (RFC 7009)?
> 
> Do you think there is a need to add more detailed information about
> these scenarios in the document? This way, we could refer back to these
> sections in the documentation in case any disputes around
> security-related topics come up.
> 
If a client revokes a valid AT, after that, the AS introspection should
answer an error response: https://tools.ietf.org/html/rfc7662#section-2.3

The problem here might be: how should the RS know if a JWT token has
been revoked on the AS?
I don't think there is a specified solution for this because it all
depends on the implementation.

The RS might use the introspection endpoint to check if a valid JWT AT
has been revoked or not.
- If the introspection endpoint is checked on some JWT AT use, it might
lead to an attack
- If the introspection endpoint is checked on every JWT AT use, then the
advantage of using a JWT AT is close to 0

There might be some kind of pushed events between the AS and the RS when
a JWT AT is revoked, to allow the RS not to introspect a JWT AT at all.
Like this, the RS knows if a JWT AT has been revoked or not.

If the client uses a proof of possession process, the revocation
endpoint may be useless, because if the client doesn't want an AT to be
used after a certain point, it just has not to use it anymore.

/Nicolas

---

From: Thomas Broyer <[email-masked]>
Date: Sun, 4 Oct 2020 17:27:41 +0200

Disclosure: I have not read the draft on JWT AT, those comments are based
only on my current knowledge of OAuth 2.0 / OpenID Connect, and JWT.

> advantage of using a JWT AT is close to 0

With a JWT AT you can check the JWT signature and detect expiry without
introspection.
But otherwise, yes, no difference.

> Like this, the RS knows if a JWT AT has been revoked or not.

If there are some kind of pushed events between the AS and the RS, then it
could push the revoked (and/or expired) opaque AT too, giving almost no
advantage to JWT ATs.

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Nicolas Mora <[email-masked]>
Date: Sun, 4 Oct 2020 12:55:13 -0400

Hello,

Le 20-10-04 à 11 h 27, Thomas Broyer a écrit :

> If there are some kind of pushed events between the AS and the RS, then
> it could push the revoked (and/or expired) opaque AT too, giving almost
> no advantage to JWT ATs.
>
Not necessarily, let's say the AS informs the RS only of the revoked
ATs, when a RS checks an AT, it verifies the signature first, then the
claims, then checks if the AT has been revoked by checking its internal
list filled by the AS pushed events.

In this model, considering that token revocations don't happen a lot,
the ratio revoked AT/valid AT is very low, so the advantage of a JWT is
important, because it means not so much communication between the AS and
the RSs, and a very reliable AT.

But this means a communication mechanism that isn't standardized yet.

/Nicolas

---

From: Jim Manico <[email-masked]>
Date: Sun, 4 Oct 2020 14:17:19 -1000

> In this model, considering that token revocations don't happen a lot...

Just a brief note, a secure piece of software makes the logout feature prominent. Every logout event should trigger token revocation.

I’m mentioning this because a lot of OAuth solutions in the mobile space literally ignore the logout event, such as Facebook’s mobile OAuth solution. 

- Jim

> On Oct 4, 2020, at 6:55 AM, Nicolas Mora <[email-masked]> wrote:
> 
> Hello,
>

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 6 Oct 2020 14:16:53 +0200

> list filled by the AS pushed events.

Well, you were the one saying that “the advantage of using a JWT AT is
close to 0” 😉
(and I was the one bringing the advantage of being able to do some
verifications prior to contacting the introspection endpoint, btw)
In any case, for an opaque AT, you only get to introspect it once to know
its expiration (and you can cache the result); so those preliminary checks
you can do with a JWT only save you one introspection request IFF the token
is not valid, e.g. expired; if it's valid or has been revoked, then you'll
have to introspect it anyway.
And if you imagine that "pushed events" mechanism, then it would work the
same for an opaque AT or a JWT AT, saving you the introspection requests
that would otherwise be mandatory for checking revocation.

So (and I know it wasn't the original subject of the discussion), a JWT AT
can save you, compared to an opaque AT:
 * a call to the userinfo endpoint if it embeds the claims you need
 * a call to the introspection endpoint if it's expired or otherwise
invalid, and/or some memory/storage space that you could use as a cache for
that information for an opaque AT (to avoid issuing other introspection
requests, as an optimization / compromise)

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

---

From: <[email-masked]>
Date: Tue, 6 Oct 2020 14:21:59 -0700

Hey Jim, regarding
> Every logout event should trigger token revocation
That isn’t necessarily the case. An access token represents the ability of a client to access a given resource; the fact that it requires an authentication transaction/session establishment to be issued to the client does not mean that the AT lifetime is tied to the lifetime of that session. Say that I allow LinkedIn to tweet on my behalf. Once I have done that, it doesn’t matter whether I stay logged in their web app or otherwise. Even if I log out of the session in which context I got my twitter AT, I can still post on LinkedIn from my native LinkedIn app and the corresponding post will show up on twitter as well.
Now, one might choose to *explicitly* tie tokens lifetime to originating sessions lifetime, see the discussion on the OpenID Connect group about a possible online_access scope for influencing RTs and Ats (in particular, in the context of SPAs) but that's additional semantic that isn’t defined today.

-----Original Message-----
From: OAuth <[email-masked]> On Behalf Of Jim Manico
Sent: Sunday, October 4, 2020 5:17 PM
To: Nicolas Mora <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

- Jim

>> If there are some kind of pushed events between the AS and the RS, 
>> then it could push the revoked (and/or expired) opaque AT too, giving 
>> almost no advantage to JWT ATs.
>> 
> claims, then checks if the AT has been revoked by checking its 
> internal list filled by the AS pushed events.
> 
> the ratio revoked AT/valid AT is very low, so the advantage of a JWT 
> is important, because it means not so much communication between the 
> AS and the RSs, and a very reliable AT.
>

---

From: Andrii Deinega <[email-masked]>
Date: Tue, 6 Oct 2020 14:25:24 -0700

Vittorio and WG,

Would it be possible to include something like the following to
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-10

In case the authorization server exposes the introspection, revocation, and
OpenID Connect userinfo endpoints they MUST act in the same way as it
happens with a regular access token. That allows the AS to change the type
of an access token on the fly and that won’t lead to interoperate issues.
Plus, the consumers of these endpoints use them regardless of the type of
access token.

The way how the AS can notify RSs that the token revocation event happened
(if it decides to do so) is completely left to implementers.

?

Another minor editorial thing from me is it would possible to change and
refer to "JWT access tokens" as AJWT. Thus, this document won't repeat the
token word twice.

Regards,
Andrii

On Tue, Oct 6, 2020 at 2:22 PM <vittorio.bertocci=[email-masked]>
wrote:

> That isn’t necessarily the case. An access token represents the ability of
> a client to access a given resource; the fact that it requires an
> authentication transaction/session establishment to be issued to the client
> does not mean that the AT lifetime is tied to the lifetime of that session.
> Say that I allow LinkedIn to tweet on my behalf. Once I have done that, it
> doesn’t matter whether I stay logged in their web app or otherwise. Even if
> I log out of the session in which context I got my twitter AT, I can still
> post on LinkedIn from my native LinkedIn app and the corresponding post
> will show up on twitter as well.
> Now, one might choose to *explicitly* tie tokens lifetime to originating
> sessions lifetime, see the discussion on the OpenID Connect group about a
> possible online_access scope for influencing RTs and Ats (in particular, in
> the context of SPAs) but that's additional semantic that isn’t defined
> today.
>
> Just a brief note, a secure piece of software makes the logout feature
> prominent. Every logout event should trigger token revocation.
>
> I’m mentioning this because a lot of OAuth solutions in the mobile space
> literally ignore the logout event, such as Facebook’s mobile OAuth
> solution.
>
> - Jim
>

---

From: Jim Manico <[email-masked]>
Date: Tue, 6 Oct 2020 11:31:15 -1000

Thanks for this message, Vittorio.

 > Say that I allow LinkedIn to tweet on my behalf. Once I have done 
that, it doesn’t matter whether I stay logged in their web app or otherwise.

Ah, of course. That makes perfect sense.

I should had been a lot more specific. I was commenting more on how many 
mobile apps which use OAuth AuthZ refresh/access tokens from the native 
client RFC do not support logout. I noticed that when I log out of the 
Facebook mobile app, my refresh token is still active and I'm not really 
fully logged out. If I am in a native client triggering a logout event, 
I would expect to see revocation in play!

Also, in an microservice environment where JWT's are used as client side 
sessions, logout events often do not actually revoke currently active 
JWT's. #lazyLogoutBooo

That's all from me. =)

Aloha, Jim

-- 
Jim Manico
Manicode Security
https://www.manicode.com

---

From: <[email-masked]>
Date: Tue, 6 Oct 2020 14:38:35 -0700

Thanks for bringing the revocation topic up. In brief:

*	I agree on the comments that differentiate between userinfo and introspection- userinfo doesn’t really play a role in validation hence I’d keep it out of the JWT AT doc.
*	I agree that the introspection endpoint shouldn’t do anything special or different for JWT ATs

The last point is more involved. 
I think that using introduction just for checking revocation would be overkill and wasteful, no point sending the entire token if it has been already validated (bandwidth) and no point for the AS to repeat checks already done by the RS, especially at large scale and for chatty solutions.
One of the reasons for making `JTI` mandatory in the profile is to provide a mechanism for handling AT revocation easier. There is no standard today for doing that. 
In some 1:1 conversations on the topic, one solution that sounds promising is for the AS to publish a list per each resource/client including all the revoked JTIs. The RS is free to fetch that list at any time and incorporate local revocation checks at whatever frequency it wants. 
The naïve alternative is to have an endpoint on the AS the RS can use to inquire on whether a given JTI has been revoked. That is less wasteful than doing a full introspection, but still network hungry.
Both alternatives have implications on the AS, now saddled with tracking possibly large numbers of tokens. There are heuristics to handle that (eg have identifiers for sessions and use those to manage revocations, rather than trating every AT as independent) and ultimately it would not be in the purview of the protocol to worry about that, but something to consider when implementing.

Would it be useful to produce normative guidance on one of the approaches above? If yes, where would that live? I am not sure the JWT AT profile is the right place, perhaps an addendum to the current revocation specs?

From: OAuth <[email-masked]> On Behalf Of Thomas Broyer
Sent: Tuesday, October 6, 2020 5:17 AM
To: Nicolas Mora <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

On Sun, Oct 4, 2020 at 6:55 PM Nicolas Mora <[email-masked] <mailto:[email-masked]> > wrote:

Hello,

Well, you were the one saying that “the advantage of using a JWT AT is close to 0” 😉

(and I was the one bringing the advantage of being able to do some verifications prior to contacting the introspection endpoint, btw)

In any case, for an opaque AT, you only get to introspect it once to know its expiration (and you can cache the result); so those preliminary checks you can do with a JWT only save you one introspection request IFF the token is not valid, e.g. expired; if it's valid or has been revoked, then you'll have to introspect it anyway.

And if you imagine that "pushed events" mechanism, then it would work the same for an opaque AT or a JWT AT, saving you the introspection requests that would otherwise be mandatory for checking revocation.

So (and I know it wasn't the original subject of the discussion), a JWT AT can save you, compared to an opaque AT:

 * a call to the introspection endpoint if it's expired or otherwise invalid, and/or some memory/storage space that you could use as a cache for that information for an opaque AT (to avoid issuing other introspection requests, as an optimization / compromise)

-- 

Thomas Broyer

---

From: <[email-masked]>
Date: Tue, 6 Oct 2020 14:42:04 -0700

Thanks for the clarification! I agree, the scenarios you described would be improved by actually killing the ability of the app to access the resources, instead on relying on the client to discard the tokens without leaking them. That's why I am a big proponent of the online_access scope, tho I know a lot of people don’t like it as it perpetrates the offline_access original sin 😊

-----Original Message-----
From: Jim Manico <[email-masked]> 
Sent: Tuesday, October 6, 2020 2:31 PM
To: [email-masked]; 'Nicolas Mora' <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

 > Say that I allow LinkedIn to tweet on my behalf. Once I have done that, it doesn’t matter whether I stay logged in their web app or otherwise.

I should had been a lot more specific. I was commenting more on how many mobile apps which use OAuth AuthZ refresh/access tokens from the native client RFC do not support logout. I noticed that when I log out of the Facebook mobile app, my refresh token is still active and I'm not really fully logged out. If I am in a native client triggering a logout event, I would expect to see revocation in play!

Also, in an microservice environment where JWT's are used as client side sessions, logout events often do not actually revoke currently active JWT's. #lazyLogoutBooo

That's all from me. =)

Aloha, Jim

On 10/6/20 11:21 AM, [email-masked] wrote:
>>> then it could push the revoked (and/or expired) opaque AT too, 
>>> giving almost no advantage to JWT ATs.
>>>
>> ATs, when a RS checks an AT, it verifies the signature first, then 
>> the claims, then checks if the AT has been revoked by checking its 
--
Jim Manico
Manicode Security
https://www.manicode.com

---

From: <[email-masked]>
Date: Tue, 6 Oct 2020 14:53:32 -0700

Hi Andrii,

Thanks for the thoughtful comments! Here’s my 2 c.

On the proposed language: given that the JWT AT profile is just providing more details on the content of an AT, making JWT ATs a proper subset of all ATs, readers should have no reason to believe that introspection or any other existing spec discussing AT behavior should operate differently. That assumption holds for everything across the board, hence it would be a bit odd to call out this particular case. On the userinfo case, I would find it even more left field to say anything about it.
If we do reach a consensus on specific revocation practices that apply to JWT ATs specifically, and we conclude that they should live in this document, I will be happy to add language accordingly.

On the AJWT: I hear you on the dissonance that JWT AT carries, but I am very hesitant to introduce new acronyms to an already crowded/impenetrable domain.
JWT access token might not roll off the tongue, but at this point ‘JWT’ is nearly a proprietary eponym and the expression “JWT token” is extraordinarily common in literature, a quick google query will give you the full measure of the phenomenon, hence I think we’ll be OK with the current form.

Cheers,

V.

From: Andrii Deinega <[email-masked]> 
Sent: Tuesday, October 6, 2020 2:25 PM
To: [email-masked]; [email-masked]
Cc: Jim Manico <[email-masked]>; Nicolas Mora <[email-masked]>
Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

Vittorio and WG,

Would it be possible to include something like the following to https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-10

In case the authorization server exposes the introspection, revocation, and OpenID Connect userinfo endpoints they MUST act in the same way as it happens with a regular access token. That allows the AS to change the type of an access token on the fly and that won’t lead to interoperate issues. Plus, the consumers of these endpoints use them regardless of the type of access token.

The way how the AS can notify RSs that the token revocation event happened (if it decides to do so) is completely left to implementers.

?

Another minor editorial thing from me is it would possible to change and refer to "JWT access tokens" as AJWT. Thus, this document won't repeat the token word twice.

Regards,

Andrii

On Tue, Oct 6, 2020 at 2:22 PM <vittorio.bertocci=[email-masked] <mailto:[email-masked]> > wrote:

Hey Jim, regarding

-----Original Message-----
From: OAuth <[email-masked] <mailto:[email-masked]> > On Behalf Of Jim Manico
Sent: Sunday, October 4, 2020 5:17 PM
To: Nicolas Mora <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

- Jim

> On Oct 4, 2020, at 6:55 AM, Nicolas Mora <[email-masked] <mailto:[email-masked]> > wrote:
> 
> Hello,
> 
> [email-masked] <mailto:[email-masked]> 

_______________________________________________
OAuth mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/oauth

---

From: Seán Kelleher <[email-masked]>
Date: Wed, 7 Oct 2020 18:45:31 +0100

Hi all,

Long time lurker, first time poster, glad to be finally getting involved!

In terms of weighing in on the revocation practice, I don't think this
document needs to address it as JWT ATs don't seem to require special
handling in this case. I think a general coverage of approaches to token
revocation would be more appropriate in a BCP.

One thing I'm unsure of when reading this is how a RS can depend on an AS
to give it a JWT AT. Due to the opaque nature of ATs, it seems natural that
an AS can change the AT profile it uses at its own discretion, but there's
no negotiation or parameter that can force an AS to return a JWT AT, with
the potential for breakages. Do the RS and AS agree on the profile ahead of
time?  Perhaps this is specified in a separate document, but I think the
topic of profile negotiation should be covered in this document, even at a
high level, or reference to more detailed coverage.

A few other notes on the document itself:

   - Section 2.1: Is there precedence of "application/at+jwt" being used in
   the wild that prevents the SHOULD from being a MUST?
   - Figure 1: Nitpick: An `&` that looks like it should prefix `state` is
   on the preceding line.
   - Figure 2: The example `typ` is `at+JWT`, should this be `at+jwt`?
   - Section 4: This is a personal opinion, but I'd recommend moving the
   step concerning `aud` validation to the top of the list, for focus. This is
   because, having personally taken more than a little while to figure out the
   difference between access tokens and ID tokens, I see the risk of cross-JWT
   confusion as very relevant. I think the necessity of the other steps are a
   bit more obvious.

Thanks!

Kind regards,

Seán.

On Tue, 6 Oct 2020 at 22:53, <vittorio.bertocci=[email-masked]>
wrote:

> On the proposed language: given that the JWT AT profile is just providing
> more details on the content of an AT, making JWT ATs a proper subset of all
> ATs, readers should have no reason to believe that introspection or any
> other existing spec discussing AT behavior should operate differently. That
> assumption holds for everything across the board, hence it would be a bit
> odd to call out this particular case. On the userinfo case, I would find it
> even more left field to say anything about it.
> If we do reach a consensus on specific revocation practices that apply to
> JWT ATs specifically, and we conclude that they should live in this
> document, I will be happy to add language accordingly.
>
>
>
> On the AJWT: I hear you on the dissonance that JWT AT carries, but I am
> very hesitant to introduce new acronyms to an already crowded/impenetrable
> domain.
> JWT access token might not roll off the tongue, but at this point ‘JWT’ is
> nearly a proprietary eponym and the expression “JWT token” is
> extraordinarily common in literature, a quick google query will give you
> the full measure of the phenomenon, hence I think we’ll be OK with the
> current form.
>
> Cheers,
>
> V.
>
>
>
> *From:* Andrii Deinega <[email-masked]>
> *Sent:* Tuesday, October 6, 2020 2:25 PM
> *To:* [email-masked]; [email-masked]
> *Cc:* Jim Manico <[email-masked]>; Nicolas Mora <[email-masked]>
> *Subject:* Re: [OAUTH-WG] JWT access tokens and the revocation endpoint
>
>
>
> Vittorio and WG,
>
>
>
> In case the authorization server exposes the introspection, revocation,
> and OpenID Connect userinfo endpoints they MUST act in the same way as it
> On Tue, Oct 6, 2020 at 2:22 PM <vittorio.bertocci=
> [email-masked]> wrote:
>
> Hey Jim, regarding

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 8 Oct 2020 12:21:26 +0200

> On 7. Oct 2020, at 19:45, Seán Kelleher <[email-masked]> wrote:
> 
> Hi all,
> 
> In terms of weighing in on the revocation practice, I don't think this document needs to address it as JWT ATs don't seem to require special handling in this case. I think a general coverage of approaches to token revocation would be more appropriate in a BCP.
> 
> One thing I'm unsure of when reading this is how a RS can depend on an AS to give it a JWT AT. Due to the opaque nature of ATs, it seems natural that an AS can change the AT profile it uses at its own discretion, but there's no negotiation or parameter that can force an AS to return a JWT AT, with the potential for breakages. Do the RS and AS agree on the profile ahead of time?  

yes, they do. Basically, the AS is acting on behalf of the RS and centralises the authorization work. 

> Perhaps this is specified in a separate document, but I think the topic of profile negotiation should be covered in this document, even at a high level, or reference to more detailed coverage.

Good point. I think this is a general assumption in OAuth. Should probably go into OAuth 2.1.

> 	• Section 2.1: Is there precedence of "application/at+jwt" being used in the wild that prevents the SHOULD from being a MUST?
> 	• Figure 1: Nitpick: An `&` that looks like it should prefix `state` is on the preceding line.
> 	• Figure 2: The example `typ` is `at+JWT`, should this be `at+jwt`?
> 	• Section 4: This is a personal opinion, but I'd recommend moving the step concerning `aud` validation to the top of the list, for focus. This is because, having personally taken more than a little while to figure out the difference between access tokens and ID tokens, I see the risk of cross-JWT confusion as very relevant. I think the necessity of the other steps are a bit more obvious.
> Thanks!
> 
> Kind regards,
> 
> Seán.
> 
> On Tue, 6 Oct 2020 at 22:53, <vittorio.bertocci=[email-masked]> wrote:
> Hi Andrii,
> 
> On Tue, Oct 6, 2020 at 2:22 PM <vittorio.bertocci=[email-masked]> wrote:
> 
> Hey Jim, regarding