+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
