I'm fine with this. Any objections? EHL
On 7/12/10 11:01 PM, "Brian Eaton" <bea...@google.com> wrote: 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
