This is why i expect a secevent token revocation event to be defined to complement 7009 once secevents moves further along.
We want to be able to know in near real time when a token is revoked to avoid constant checks to see if a token is still good. Phil > On Jun 6, 2017, at 3:18 PM, Justin Richer <[email protected]> wrote: > > That really depends on the nature of your tokens and how you manage their > internal validity. It’s really as soon as possible, isn’t it? If you can > invalidate it immediately, do that. In our implementation, we delete it from > the data store as soon as the revocation request comes in, which invalidates > it. Downstream RS’s might have cached introspection (RFC7662) results so > they’ll find out once their caches expire. If you’ve got some other > synchronization method that takes some time to propagate, then that’s going > to be the answer. All of this is dependent on your implementation and not on > the revocation protocol, but in all cases I see no reason to *wait* any > amount of time to revoke a token that’s been requested for revocation by a > client, for any reason. The client is effectively saying “if you see this > token again it isn’t from me”, which should be a good enough indication to > throw it out as soon as possible. > > This all falls apart if you’re using self-contained tokens — there’s not a > good way to invalidate a self-contained token without using some kind of > lookup service. RFC7662 defines such a service for OAuth, but then your > tokens aren’t really fully self-contained anymore and you’re simply stuck > waiting for the compromised token to expire. > > — Justin > >> On Jun 6, 2017, at 6:11 PM, Brig Lamoreaux <[email protected]> >> wrote: >> >> This is where we have the question around timeouts. If the client thinks its >> token is compromised, how long should 7009 take to invalidate. >> >> >> >> From: Justin Richer [mailto:[email protected]] >> Sent: Tuesday, June 6, 2017 2:46 PM >> To: Brig Lamoreaux <[email protected]> >> Cc: <[email protected]> <[email protected]> >> Subject: Re: [OAUTH-WG] RFC 7009 >> >> 7009 doesn't, really. If the client thinks its token is compromised, it can >> revoke it using 7009. If the server decides the token is compromised, it >> invalidates it on its own, not involving 7009. The client finds out the >> token isn't good anymore the next time it tries to use the token -- OAuth >> clients always need to be prepared for their token not working at some >> point. Good news is that the remedy for having a token that doesn't work is >> to just do OAuth again. >> >> -- Justin >> >> >> On 6/6/2017 5:43 PM, Brig Lamoreaux wrote: >> Thanks for the reply. How do the RFC address a token that has been >> compromised? >> >> From: Justin Richer [mailto:[email protected]] >> Sent: Tuesday, June 6, 2017 9:12 AM >> To: Brig Lamoreaux <[email protected]> >> Cc: <[email protected]> <[email protected]> >> Subject: Re: [OAUTH-WG] RFC 7009 >> >> OAuth doesn’t specify and specific timeout period, it’s up to the AS that >> issues the token to determine how long the token is good for. RFC7009 isn’t >> about timeout periods, it’s about the client proactively telling the AS that >> it doesn’t need a token anymore and the AS should throw it out, likely prior >> to any timeouts. >> >> — Justin >> >> On May 25, 2017, at 12:23 PM, Brig Lamoreaux <[email protected]> >> wrote: >> >> Hi, >> >> What is the specified timeout period to invalidate the token? >> >> Brig Lamoreaux >> Data Solution Architect >> [email protected] >> 480-828-8707 >> US Desert/Mountain Tempe >> >> >> <image001.jpg> >> >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=7yMIczBrZnmQ14Nkf4MBGaIHnxRyiLGXB1Xhuxp1Ur0&s=TaKHdPgtEPkCV_YuOHlkoXRZJjf0k8Y4-yowD3YbhPw&e= >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
