Subject: [OAUTH-WG] expired_token error code

From: Brian Eaton <[email-masked]>
Date: Mon, 12 Jul 2010 23:01:02 -0700

http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5.2.1

The "expired_token" error code doesn't scale well and won't be
implemented reliably.  It should be merged with "invalid_token".

Suggested language:

invalid_token
         The access token provided is invalid.  Resource servers
SHOULD use this error code when receiving a token which is expired,
revoked, malformed, or invalid for other reasons.  The resource server
MUST respond with the HTTP 401 (Unauthorized) status code.  The client
MAY request a new access token and retry the protected resource
request.

"expired_token" can't be implemented reliably for a few reasons.

1) If you're using server-side storage of tokens (which you need to do
if you want to keep your tokens very short...) you have to throw away
tokens after they expire.  Just because you can't validate the token
doesn't mean the client can't refresh the token.

2) If you're using cryptographic access tokens, you need to throw away
your old token signing keys at some point.  Again, just because you
can't validate a token doesn't mean the client can't refresh the
token.

3) One common deployment model will have limited communication between
authorization servers and protected resource servers.  The protected
resource server might not be able to contact the authorization server
to figure out whether refresh tokens are available or not.

4) The access token may not have enough information in it to look-up
the corresponding refresh token and see if it's still valid.
Remembering that information requires extra space in the access token
for cryptographic token implementations.  Space is tight.

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 13 Jul 2010 07:20:39 -0700

I'm fine with this. Any objections?

EHL

On 7/12/10 11:01 PM, "Brian Eaton" <[email-masked]> wrote:

Suggested language:

invalid_token

Cheers,
Brian
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: "William Mills" <[email-masked]>
Date: Tue, 13 Jul 2010 09:54:46 -0700

+1

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eran Hammer-Lahav
	Sent: Tuesday, July 13, 2010 7:21 AM
	To: Brian Eaton; OAuth WG; [email-masked]
	Subject: Re: [OAUTH-WG] expired_token error code

	EHL

	
		
		The "expired_token" error code doesn't scale well and
won't be
		implemented reliably.  It should be merged with
"invalid_token".
		
		Suggested language:
		
		invalid_token
		         The access token provided is invalid.  Resource
servers
		SHOULD use this error code when receiving a token which
is expired,
		revoked, malformed, or invalid for other reasons.  The
resource server
		MUST respond with the HTTP 401 (Unauthorized) status
code.  The client
		MAY request a new access token and retry the protected
resource
		request.

		"expired_token" can't be implemented reliably for a few
reasons.
		
		1) If you're using server-side storage of tokens (which
you need to do
		if you want to keep your tokens very short...) you have
to throw away
		tokens after they expire.  Just because you can't
validate the token
		doesn't mean the client can't refresh the token.
		
		2) If you're using cryptographic access tokens, you need
to throw away
		your old token signing keys at some point.  Again, just
because you
		can't validate a token doesn't mean the client can't
refresh the
		token.
		
		3) One common deployment model will have limited
communication between
		authorization servers and protected resource servers.
The protected
		resource server might not be able to contact the
authorization server
		to figure out whether refresh tokens are available or
not.
		
		4) The access token may not have enough information in
it to look-up
		the corresponding refresh token and see if it's still
valid.
		Remembering that information requires extra space in the
access token
		for cryptographic token implementations.  Space is
tight.
		
		Cheers,
		Brian