Subject: [OAUTH-WG] RFC 7009

From: Brig Lamoreaux <[email-masked]>
Date: Thu, 25 May 2017 16:23:12 +0000

Hi,

What is the specified timeout period to invalidate the token?

Brig Lamoreaux

Data Solution Architect
[email-masked]<mailto:[email-masked]>
480-828-8707
US Desert/Mountain Tempe

[MSFT_logo_Gray DE sized SIG1.png]

---

From: Justin Richer <[email-masked]>
Date: Tue, 6 Jun 2017 12:12:07 -0400

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-masked]> wrote:
> 
> Hi,
> 
> [email-masked] <mailto:[email-masked]>
> 480-828-8707
> US Desert/Mountain Tempe
>  
>  
>  
>  
>  
> _______________________________________________
> OAuth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Justin Richer <[email-masked]>
Date: Tue, 6 Jun 2017 17:45:39 -0400

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-masked]]
> *Sent:* Tuesday, June 6, 2017 9:12 AM
> *To:* Brig Lamoreaux <[email-masked]>
> *Cc:* <[email-masked]> <[email-masked]>
> *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-masked]
>     <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>
>     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>
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 6 Jun 2017 18:18:24 -0400

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-masked]> 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-masked]] 
> Sent: Tuesday, June 6, 2017 2:46 PM
> To: Brig Lamoreaux <[email-masked]>
> Cc: <[email-masked]> <[email-masked]>
> 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
> 
>  
> Thanks for the reply. How do the RFC address a token that has been compromised?
>  
> From: Justin Richer [mailto:[email-masked] <mailto:[email-masked]>] 
> Sent: Tuesday, June 6, 2017 9:12 AM
> To: Brig Lamoreaux <[email-masked]> <mailto:[email-masked]>
> Cc: <[email-masked]> <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
> Subject: Re: [OAUTH-WG] RFC 7009
>  
> On May 25, 2017, at 12:23 PM, Brig Lamoreaux <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi,
> 
> 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>
>  
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Tue, 6 Jun 2017 15:31:54 -0700

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-masked]> wrote:
> 
>> [email-masked]
>> 480-828-8707
>> US Desert/Mountain Tempe
>>  
>>  
>>  
>>  
>>  
>> [email-masked]
> [email-masked]
> 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=

---

From: Brig Lamoreaux <[email-masked]>
Date: Tue, 6 Jun 2017 21:43:20 +0000

— Justin

On May 25, 2017, at 12:23 PM, Brig Lamoreaux <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Brig Lamoreaux

Data Solution Architect

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
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>

---

From: Brig Lamoreaux <[email-masked]>
Date: Tue, 6 Jun 2017 22:11:24 +0000

-- Justin

From: Justin Richer [mailto:[email-masked]]
Sent: Tuesday, June 6, 2017 9:12 AM
To: Brig Lamoreaux <[email-masked]><mailto:[email-masked]>
Cc: <[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: [OAUTH-WG] RFC 7009

 — Justin

Hi,

Brig Lamoreaux

Data Solution Architect

---

From: Justin Richer <[email-masked]>
Date: Wed, 7 Jun 2017 11:09:47 -0400

Agree, and this was discussed at the time of 7662’s ratification but there was no agreement on a delivery mechanism. I’d like to see a SECEVENT with a 7662 payload, which would take care of a large number of use cases, including “token revoked” and “new token issued” being delivered downstream to RS’s. It’s a good compliment to the callback-based mechanism in 7662.

 — Justin

> On Jun 6, 2017, at 6:31 PM, Phil Hunt (IDM) <[email-masked]> wrote:
> 
> On Jun 6, 2017, at 3:18 PM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>> On Jun 6, 2017, at 6:11 PM, Brig Lamoreaux <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> To: Brig Lamoreaux <[email-masked] <mailto:[email-masked]>>
>>> Cc: <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Foauth-26data-3D02-257C01-257CBrig.Lamoreaux-2540microsoft.com-257C538020425e8a411a106408d4acf6ca32-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636323623328232170-26sdata-3DUHQOwegm2k8MbWPCYHR3a4ted39xMFlfjil4FdJqyA8-253D-26reserved-3D0&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=7yMIczBrZnmQ14Nkf4MBGaIHnxRyiLGXB1Xhuxp1Ur0&s=mGIUcqB4BzW6-s_7X9QmZ5qldZNN__gUjCG209QWW4c&e=>
>>>  
>>>  
>> 
>> 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= <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=>