[OAUTH-WG] RFC 7009

[Brig Lamoreaux]

Hi,

What is the specified timeout period to invalidate the token?

Brig Lamoreaux

Data Solution Architect
***@microsoft.com<mailto:***@microsoft.com>
480-828-8707
US Desert/Mountain Tempe



[MSFT_logo_Gray DE sized SIG1.png]

[Justin Richer]

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

Post by Brig Lamoreaux
Hi,
What is the specified timeout period to invalidate the token?
Brig Lamoreaux
Data Solution Architect
480-828-8707
US Desert/Mountain Tempe
<image001.jpg>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

[Justin Richer]

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?
*Sent:* Tuesday, June 6, 2017 9:12 AM
*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
Hi,
What is the specified timeout period to invalidate the token?
Brig Lamoreaux
Data Solution Architect
480-828-8707
US Desert/Mountain Tempe
<image001.jpg>
_______________________________________________
OAuth mailing list
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>

[Justin Richer]

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

This is where we have the question around timeouts. If the client thinks its token is compromised, how long should 7009 take to invalidate.
  <>
Sent: Tuesday, June 6, 2017 2:46 PM
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?
Sent: Tuesday, June 6, 2017 9:12 AM
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
Hi,
What is the specified timeout period to invalidate the token?
Brig Lamoreaux
Data Solution Architect
480-828-8707
US Desert/Mountain Tempe
<image001.jpg>
_______________________________________________
OAuth mailing list
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>

[Phil Hunt (IDM)]

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

Post by Justin Richer
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

This is where we have the question around timeouts. If the client thinks its token is compromised, how long should 7009 take to invalidate.
Sent: Tuesday, June 6, 2017 2:46 PM
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?
Sent: Tuesday, June 6, 2017 9:12 AM
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
Hi,
What is the specified timeout period to invalidate the token?
Brig Lamoreaux
Data Solution Architect
480-828-8707
US Desert/Mountain Tempe
<image001.jpg>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
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=

[Justin Richer]

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

Post by Phil Hunt (IDM)
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

Post by Justin Richer
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

This is where we have the question around timeouts. If the client thinks its token is compromised, how long should 7009 take to invalidate.
  <>
Sent: Tuesday, June 6, 2017 2:46 PM
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?
Sent: Tuesday, June 6, 2017 9:12 AM
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
Hi,
What is the specified timeout period to invalidate the token?
Brig Lamoreaux
Data Solution Architect
480-828-8707
US Desert/Mountain Tempe
<image001.jpg>
_______________________________________________
OAuth mailing list
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=>

_______________________________________________
OAuth mailing list
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=>