Subject: [OAUTH-WG] expired access token : deserves unique code?

From: Paul Walker <[email-masked]>
Date: Fri, 7 Jan 2011 16:53:10 -0800

As far as I can tell (which isn't very far on many Friday afternoons), there is no way for a client to distinguish an expired access token from a revoked, malformed, etc token as the invalid_token error parameter value encompasses multiple scenarios.  Of course, a client could parse the error_description, but this is an optional parameter with no guaranty of a common value among providers.

Given that the client would want to make an explicit decision to request another access token using a refresh token (if available), would it not benefit clients if a specific error parameter value was defined for this scenario?

---

From: William Mills <[email-masked]>
Date: Fri, 7 Jan 2011 17:24:02 -0800

You're giving away more information than you need to here.  The result is almost always the same, go back to the token issuer and get a new token of the type you need.  I think what we're playing against here is ease of debugging the server with your client, "Why should I get an invalid token error with a new token?" and similar questions.

I think this is something best left to implementers to put in their own debugging, and not build it into the protocol.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Walker
> Sent: Friday, January 07, 2011 4:53 PM
> To: OAuth WG
> Subject: [OAUTH-WG] expired access token : deserves unique code?
> 
> As far as I can tell (which isn't very far on many Friday afternoons),
> there is no way for a client to distinguish an expired access token
> from a revoked, malformed, etc token as the invalid_token error
> parameter value encompasses multiple scenarios.  Of course, a client
> could parse the error_description, but this is an optional parameter
> with no guaranty of a common value among providers.
> 
> Given that the client would want to make an explicit decision to
> request another access token using a refresh token (if available),
> would it not benefit clients if a specific error parameter value was
> defined for this scenario?
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Paul Walker <[email-masked]>
Date: Fri, 7 Jan 2011 18:07:35 -0800

I am not concerned with simplifying client development debugging as much as the ability for clients to have the proper production logic.  The best that clients can do is always attempt a superfluous token refresh though the reason may be do to an end user revocation for example.

---

From: William Mills <[email-masked]>
Date: Fri, 7 Jan 2011 19:13:24 -0800

But it's not superfluous.  Their token failed, the only thing they can do to fix it is refresh it.

> From: Paul Walker [mailto:[email-masked]]
> Sent: Friday, January 07, 2011 6:08 PM
> To: William Mills
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] expired access token : deserves unique code?
> 
> I am not concerned with simplifying client development debugging as
> much as the ability for clients to have the proper production logic.
> The best that clients can do is always attempt a superfluous token
> refresh though the reason may be do to an end user revocation for
> example.
> 
> > You're giving away more information than you need to here.  The
> result is almost always the same, go back to the token issuer and get a
> new token of the type you need.  I think what we're playing against
> here is ease of debugging the server with your client, "Why should I
> get an invalid token error with a new token?" and similar questions.
> >
> > I think this is something best left to implementers to put in their
> own debugging, and not build it into the protocol.
> >

---

From: Paul Walker <[email-masked]>
Date: Fri, 7 Jan 2011 19:42:16 -0800

It's superfluous if the reason is anything but the token expired.  A specific response code allows the client to decide not to make a request when it is anything but.  Otherwise, we are making the client attempt a refresh that may not (from the client's perspective) succeed when this information was already known by the provider and could have been communicated to the client in the initial response for the resource.

---

From: William Mills <[email-masked]>
Date: Fri, 7 Jan 2011 20:31:20 -0800

All the cases like invalid format and validation errors are stuff I think you don't want to tell a hacker trying to muck with your tokens.

> Sent: Friday, January 07, 2011 7:42 PM
> To: William Mills
> Cc: OAuth WG
> It's superfluous if the reason is anything but the token expired.  A
> specific response code allows the client to decide not to make a
> request when it is anything but.  Otherwise, we are making the client
> attempt a refresh that may not (from the client's perspective) succeed
> when this information was already known by the provider and could have
> been communicated to the client in the initial response for the
> resource.
> 
>

---

From: Paul Walker <[email-masked]>
Date: Fri, 7 Jan 2011 21:45:42 -0800

Absolutely.  I am not suggesting making specific error parameter values for those scenarios.  But there are scenarios in which a valid and validated client can benefit from a more specific error value.

if response is expired token
	refresh token
else /* token has been revoked */
	initiate authorization
...

vs

if token is invalid
	if not able to refresh token  /* let's give it a shot even if the end user revoked me */
		initiate authorization
...

---

From: William Mills <[email-masked]>
Date: Fri, 7 Jan 2011 21:52:01 -0800

But so the round trip we're saving is the call to the refresh entrypoint which would give a failure and require a new authentication, you just want to go straight to the authentication.  Yeah, returning an "auth failed" instead of token expired" would solve that, is it truly worth it?

> Sent: Friday, January 07, 2011 9:46 PM
> To: William Mills
> Cc: OAuth WG
> Absolutely.  I am not suggesting making specific error parameter values
> for those scenarios.  But there are scenarios in which a valid and
> validated client can benefit from a more specific error value.
> 
> > All the cases like invalid format and validation errors are stuff I
> think you don't want to tell a hacker trying to muck with your tokens.
> >

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 8 Jan 2011 00:10:19 -0700

http://www.ietf.org/mail-archive/web/oauth/current/msg03734.html

> As far as I can tell (which isn't very far on many Friday afternoons), there is no
> way for a client to distinguish an expired access token from a revoked,
> malformed, etc token as the invalid_token error parameter value
> encompasses multiple scenarios.  Of course, a client could parse the
> error_description, but this is an optional parameter with no guaranty of a
> common value among providers.
> 
> Given that the client would want to make an explicit decision to request
> another access token using a refresh token (if available), would it not benefit
> clients if a specific error parameter value was defined for this scenario?
>

---

From: Paul Walker <[email-masked]>
Date: Fri, 7 Jan 2011 22:08:26 -0800

yes, exactly.  i'm not really passionate about it, but noticed during development as something i would want and felt kind of "stuck" in not being able to communicate this specific condition to clients (other than to parse the error_description).  my feeling is that it would only add value.

---

From: Jitesh Bhate <[email-masked]>
Date: Sat, 8 Jan 2011 08:57:50 -0500

I agree with Paul , we ran into similar issue with invalid_token status and have to rely on error_description to give/get exact cause of error..

Jitesh Bhate

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Walker [[email-masked]]
Sent: Saturday, January 08, 2011 1:08 AM
To: William Mills
Cc: OAuth WG
Subject: Re: [OAUTH-WG] expired access token : deserves unique code?

---

From: Jitesh Bhate <[email-masked]>
Date: Sat, 8 Jan 2011 10:07:26 -0500

though access token gives expiration info. that can be used when server returns  Invalid_token code to determine need to refresh token
or Initiate authorization ( but I have  got requests from our many client side developers to differentiate invalidate token vs expired token)

Jitesh

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Jitesh Bhate [[email-masked]]
Sent: Saturday, January 08, 2011 8:57 AM
To: Paul Walker; William Mills
Cc: OAuth WG
Subject: Re: [OAUTH-WG] expired access token : deserves unique code?

Jitesh Bhate

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 8 Jan 2011 23:49:43 -0700

We can add it back in, but put a note that invalid may mean expired in some cases where the server cannot tell or doesn't want to tell.

EHL

> Of Jitesh Bhate
> Sent: Saturday, January 08, 2011 7:07 AM
> To: Jitesh Bhate; Paul Walker; William Mills
> Cc: OAuth WG
> though access token gives expiration info. that can be used when server
> returns  Invalid_token code to determine need to refresh token or Initiate
> authorization ( but I have  got requests from our many client side developers
> to differentiate invalidate token vs expired token)
> 
> Jitesh
> 
> I agree with Paul , we ran into similar issue with invalid_token status and
> have to rely on error_description to give/get exact cause of error..
> 
> Jitesh Bhate
> 
> yes, exactly.  i'm not really passionate about it, but noticed during
> development as something i would want and felt kind of "stuck" in not being
> able to communicate this specific condition to clients (other than to parse the
> error_description).  my feeling is that it would only add value.
> 
> > But so the round trip we're saving is the call to the refresh entrypoint which
> would give a failure and require a new authentication, you just want to go
> straight to the authentication.  Yeah, returning an "auth failed" instead of
> token expired" would solve that, is it truly worth it?
> >
> >> Absolutely.  I am not suggesting making specific error parameter
> >> values for those scenarios.  But there are scenarios in which a valid
> >> and validated client can benefit from a more specific error value.
> >>
> >>>> It's superfluous if the reason is anything but the token expired.
> >>>> A specific response code allows the client to decide not to make a
> >>>>>> The best that clients can do is always attempt a superfluous
> >>>>>> token refresh though the reason may be do to an end user
> >>>>>> revocation for example.
> >>>>>>
> >>>>>> here is ease of debugging the server with your client, "Why
> >>>>>> should
> >> I
> >>>>>>>> From: [email-masked] [mailto:[email-masked]]
> On
> >>>>>> Behalf
> >>>>>>>> Of Paul Walker
> >>>>>>>> Given that the client would want to make an explicit decision
> >>>>>>>> to request another access token using a refresh token (if
> >> available),
> >>>>>>>> would it not benefit clients if a specific error parameter
> >>>>>>>> value
> >>>> was

---

From: Paul Walker <[email-masked]>
Date: Sun, 9 Jan 2011 00:59:19 -0800

Brian, Eran, et all

I don't understand the need to discard relevant data while the authorization between end user and provider are valid.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 9 Jan 2011 13:41:33 -0700

I don't have an opinion on this. On this matter, I simply follow consensus. If you feel strong about an expired error value, just ask for it to be put back in and we can negotiate the language. That's all it takes. But keep in mind we are at the end of the process so if you want it back, we need to do it in -12 which is coming this week.

EHL

> Sent: Sunday, January 09, 2011 12:59 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Paul Walker
> >> As far as I can tell (which isn't very far on many Friday
> >> afternoons), there is no way for a client to distinguish an expired
> >> access token from a revoked, malformed, etc token as the
> >> invalid_token error parameter value encompasses multiple scenarios.
> >> Of course, a client could parse the error_description, but this is an
> >> optional parameter with no guaranty of a common value among
> providers.
> >>
> >> would it not benefit clients if a specific error parameter value was defined
> for this scenario?
> >>