Re: [OAUTH-WG] Access Token Response without expires_in

It's a hint to the client so that well-behaved clients don't need to fail with a limited use token to know that it's probably bad. It lets you throw it away and re-auth early.

 -- Justin

________________________________
From: William Mills [wmills@yahoo-inc.com]
Sent: Tuesday, January 17, 2012 12:00 PM
To: Paul Madsen; Richer, Justin P.
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Access Token Response without expires_in

Does this require an extension?  That seems something easy to overload on scope.

________________________________
From: Paul Madsen <paul.madsen@gmail.com>
To: "Richer, Justin P." <jricher@mitre.org>
Cc: OAuth WG <oauth@ietf.org>
Sent: Tuesday, January 17, 2012 5:23 AM
Subject: Re: [OAUTH-WG] Access Token Response without expires_in

Separate from the question posed here, we are seeing customer demand for one-time semantics, but agree with Justin that this would best belong in a dedicated extension parameter and not the default

paul

On 1/16/12 10:29 PM, Richer, Justin P. wrote:

I think #3.

#1 will be a common instance, and #2 (or its variant, a limited number of uses) is a different expiration pattern than time that would want to have its own expiration parameter name. I haven't seen enough concrete use of this pattern to warrant its own extension though.

Which is why I vote #3 - it's a configuration issue. Perhaps we should rather say that the AS "SHOULD document the token behavior in the absence of this parameter, which may include the token not expiring until explicitly revoked, expiring after a set number of uses, or other expiration behavior." That's a lot of words here though.

 -- Justin

On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote:

A question came up about the access token expiration when expires_in is not included in the response. This should probably be made clearer in the spec. The three options are:

1. Does not expire (but can be revoked)
2. Single use token
3. Defaults to whatever the authorization server decides and until revoked

#3 is the assumed answer given the WG history. I'll note that in the spec, but wanted to make sure this is the explicit WG consensus.

EHL

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth