It's perfectly reasonable that the AS needs to revoke an Access Token,
yes; but why does the client need to know ahead of time? The client will
find out as soon as it tries to use the bad token at the RS, won't it?
It's a different question entirely of how the RS finds out that a token
has been revoked at the AS, but I would argue that the AS-RS connection
is very different from the AS-Client and Client-RS connections, and
should be approached differently. This is where token introspection can
really come into play -- a backchannel means of finding out what a token
is good for. As Bill pointed out, the Client generally doesn't care
about what's in the token or what it's good for in a 3-legged OAuth
case. But the eventual audience of that token, the RS, does care, and if
it's been separated from the AS, then introspection is a simple, general
way to solve that.
-- Justin
On 09/11/2012 04:48 AM, Hannes Tschofenig wrote:
Hi Justin,
I completely agree that a mechanism for the Authorization Server to notify the
Clients may not be desireable in all cases.
However, if the Authorization Server hands out long lived tokens then it may
want to notify the Clients (particularly when those are Web servers) about
revocations.
Alternatively, one could argue for short-lived tokens.
In my view it is quite realistic that the Authorization Servers finds out that
it has to revoke an Access Token.
Ciao
Hannes
On Sep 10, 2012, at 4:49 PM, Justin Richer wrote:
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
