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
On 10/6/20 11:21 AM, vittorio.berto...@auth0.com wrote:
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 <oauth-boun...@ietf.org> On Behalf Of Jim Manico
Sent: Sunday, October 4, 2020 5:17 PM
To: Nicolas Mora <nico...@babelouest.org>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint
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 <nico...@babelouest.org> wrote:
Hello,
Le 20-10-04 à 11 h 27, Thomas Broyer a écrit :
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 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Jim Manico
Manicode Security
https://www.manicode.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
