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
