[Openid-specs-ab] Potential tickets to file

George Fletcher gffletch at aol.com
Wed Jan 18 16:14:41 UTC 2012


I think the "offline_access" issue is important. Here is how we are 
planning to approach it (whether for OAuth2 or OpenID Connect).

If the "offline_access" scope is not present in the scope list, then all 
access_tokens and refresh_tokens will be tied to the lifetime of the 
authenticate session created by the flow. This means that when the user 
logs out, all access_tokens and refresh_tokens are revoked.

if the "offline_access" scope is specified, then the refresh_token (and 
subsequently the access_tokens) are NOT tied to the authentication 
session. They live beyond the current session. However, the 
access_tokens still have a "short" time to live. They are not single 
use. Asking the client to get single use tokens for every request is not 
going to work for many use cases.

When it comes to the actual lifetime of the access_token, I think that 
decision needs to be made by the Authorization Server and could change 
depending on the "risk" of the requested scopes among other factors. 
Since the protocols allow the AS to specify the expiry time, it seems 
like we don't need to specify that in the spec.

If we need to document something for interop and conformance, I'd prefer 
to do so at the level of tokens being tied to the authentication session 
or not.

Thanks,
George

On 1/17/12 8:22 PM, John Bradley wrote:
> 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> 
>> [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 
>> <mailto: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 
>> <mailto: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 caninterop make this consistent across IdP.
>>     John
>>
>>     _______________________________________________
>>     Openid-specs-ab mailing list
>>     Openid-specs-ab at lists.openid.net
>>     <mailto:Openid-specs-ab at lists.openid.net>
>>     http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>
>
>
> _______________________________________________
> 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/20120118/38be959f/attachment-0001.html>


More information about the Openid-specs-ab mailing list