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
