[Openid-specs-ab] Potential tickets to file

Nat Sakimura sakimura at gmail.com
Wed Jan 18 16:53:47 UTC 2012


Let me see.

One of the primary example of use of access_token in OAuth is an
access_token to Smart Phone clients. e.g., twitter client on an iPhone.
That one did not ask for "offline_access" scope but it is valid even when
I am logged out of web session.

As a delegation protocol, it seems to me that the default for OAuth
access_token
actually allows offline access. (Whether that is a good practice is
another issue.)

So I am not entirely sure if mandating offline_access scope for such cases
would sell well in the industry.

On the other hand, specifying the semantics of expires_in=0 would be
good, I think.

=nat



On Thu, Jan 19, 2012 at 1:14 AM, George Fletcher <gffletch at aol.com> wrote:
> 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] 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
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> 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
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


More information about the Openid-specs-ab mailing list