The use case for a client revoking a token is one of a well-behaved and
well-intentioned client being "logged out", uninstalled, or otherwise
decommissioned. In these cases, you want to have a mechanism for a
client saying to the AS, "Hey, I don't need this token anymore, get rid
of it. Incidentally, if anyone else tries using it, then it's not me."
As you point out, it doesn't help the case of a client being compromised
-- since why would a compromised client revoke its own tokens?
-- Justin
On 09/11/2012 11:21 AM, William Mills wrote:
I think a resource server might validly revoke a token, but that a client will
not.
-bill
----- Original Message -----
From: Hannes Tschofenig <[email protected]>
To: William Mills <[email protected]>
Cc: Hannes Tschofenig <[email protected]>; Torsten Lodderstedt <[email protected]>;
Justin Richer <[email protected]>; "[email protected] WG" <[email protected]>
Sent: Tuesday, September 11, 2012 1:49 AM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-00
Hi Bill,
if I read your post correctly then you are saying that you do not like what is in
<draft-ietf-oauth-revocation-00>
Did I understood you correctly?
Ciao
Hannes
On Sep 11, 2012, at 7:45 AM, William Mills wrote:
Well, the only way the client would request revocation is if the client thinks
the token is compromised, e.g. that the client has done dumb stuff. In that
sense I think the client requesting revocation makes no sense.
I am also not in favor of token introspection endpoints at all, the client
should already have all of the information it needs about the token.
From: Torsten Lodderstedt <[email protected]>
To: Justin Richer <[email protected]>
Cc: "[email protected] WG" <[email protected]>
Sent: Monday, September 10, 2012 12:55 PM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-00
+1
Am 10.09.2012 15:49, schrieb Justin Richer:
That requires the client and/or resource server to run an endpoint of their own
at all times, and it requires the AS to keep track of all instances of a client
and RS. This isn't likely to be particularly desirable, scalable, or usable. I
don't see too much harm in trying to define it, but I don't think it will see
much adoption.
Besides, the client can find out the token is revoked by just presenting it to
the RS and getting back a 40x code. Clients don't really need anything faster
than that for security reasons, and any shortcuts would be for performance. The
connection between the RS and AS isn't defined -- but I think this is another
instance where the generic token introspection endpoint makes more sense. If
the RS wants to check, the AS can just tell it (via introspection) that the
token was revoked so don't honor it.
-- Justin
On 09/10/2012 08:25 AM, Hannes Tschofenig wrote:
The current draft defines an additional endpoint, the token revocation
endpoint, so that clients can request the revocation of a particular token.
Wouldn't it make sense to also allow Authorization Servers to tell Clients or
Resource Servers to revoke tokens?
Ciao
Hannes
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
