+1

________________________________

        From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of Eran Hammer-Lahav
        Sent: Tuesday, July 13, 2010 7:21 AM
        To: Brian Eaton; OAuth WG; b...@google.com
        Subject: Re: [OAUTH-WG] expired_token error code
        
        
        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

Reply via email to