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 <brig.lamore...@microsoft.com> > 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:jric...@mit.edu] > Sent: Tuesday, June 6, 2017 2:46 PM > To: Brig Lamoreaux <brig.lamore...@microsoft.com> > Cc: <oauth@ietf.org> <oauth@ietf.org> > 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:jric...@mit.edu <mailto:jric...@mit.edu>] > Sent: Tuesday, June 6, 2017 9:12 AM > To: Brig Lamoreaux <brig.lamore...@microsoft.com> > <mailto:brig.lamore...@microsoft.com> > Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> > <mailto:oauth@ietf.org> > 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 <brig.lamore...@microsoft.com > <mailto:brig.lamore...@microsoft.com>> wrote: > > Hi, > > What is the specified timeout period to invalidate the token? > > Brig Lamoreaux > Data Solution Architect > brig.lamore...@microsoft.com <mailto:brig.lamore...@microsoft.com> > 480-828-8707 > US Desert/Mountain Tempe > > > <image001.jpg> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CBrig.Lamoreaux%40microsoft.com%7C538020425e8a411a106408d4acf6ca32%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636323623328232170&sdata=UHQOwegm2k8MbWPCYHR3a4ted39xMFlfjil4FdJqyA8%3D&reserved=0> > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
