[Openid-specs-ab] Potential tickets to file

John Bradley ve7jtb at ve7jtb.com
Wed Jan 18 01:22:45 UTC 2012


I think we should track the issue.

We could easily get different IdP assigning different meanings to expires_in=0 etc.

I don't know what the correct answer is at the moment, but I see it as a potential interop problem for clients.

John 
On 2012-01-17, at 7:36 PM, Mike Jones wrote:

> I don’t see a compelling case for baking token lifetime decisions into the specs at this time.  This seems like an area where we would profitably learn from implementation experiences, once a number of them have been in production and specific issues and choices faced can be identified and described.
>  
>                                                             -- Mike
>  
> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat Sakimura
> Sent: Tuesday, January 17, 2012 2:10 PM
> To: John Bradley
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Potential tickets to file
>  
> Good point. 
>  
> In addition, sometimes it is useful to have a token that survives password change as well. E.g., the token for email clients while using OTP on the web side.  
> 
> Nat Sakimura
> 
> On 2012/01/18, at 4:53, John Bradley <ve7jtb at ve7jtb.com> wrote:
> 
> Do we need a standard scope for requesting offline access (long-lived access token)?
>  
> Some IdP use a scope for offline_access.
>  
> Enables your application to perform authorized requests on behalf of the user at any time. By default, most access tokens expire after a short time period to ensure applications only make requests on behalf of the user when the are actively using the application. This permission makes the access token returned by our OAuth endpoint long-lived.
>  
> What is the default openID Connect access token lifetime without such a scope?
>  
> Single use? 30min? Session duration?
>  
> There are also some undefined states in OAuth 2.0 with expires_in.
>  
> I would propose that openID connect access tokens are single use by default.  
>  
> A server not sending expires_in is indicating default expiry behavior.
>  
> A server may make them longer lived by indicating that with expires_in.
>  
> A value of 0 for expires_in indicates the token will not expire due to time, though it may due to password reset or users revoking access.
>  
> Facebook seems to use the 0 value but I can't find it documented anyplace.
>  
> If we go with single use the client can always get another token,  and the client doesn't need to worry about storing access tokens in the simple case. 
>  
> It will help  if we can interop make this consistent across IdP.
>  
> John
>  
>  
>  
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120117/5b141aaf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120117/5b141aaf/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list