Subject: Re: [OAUTH-WG] Authorization code use in draft-ietf-oauth-v2-21

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 9 Sep 2011 16:06:29 -0700

Sending to the right address. 

EHL

On Sep 9, 2011, at 15:31, "André DeMarre" <[email-masked]> wrote:

> Greetings Everyone,
> 
> I hope the draft isn't too far along for these comments.
> (draft-ietf-oauth-v2-21)
> 
> 1. AUTHORIZATION CODE RESTRICTIONS
> 
> The specification (particularly Section 4.1) does not say if the
> authorization server may or may not allow an authorization code to be
> used more than once in exchange for an access token. (Section 4.1.3)
> 
> With this ambiguity, some authorization server implementations might
> allow authorization codes to be reused by the client (whether
> intentionally or not). I don't see any benefit in allowing this and
> think it should be forbidden for several reasons.
> 
> Allowing this enables a scenario where an authorization code may be
> reused when the client should use the refresh token instead. The
> refresh token has more desirable security properties.
> 
> The usefulness of authorization codes should be restricted wherever
> possible because they are revealed to resource owners and can be sent
> over unsecure connections when the client does not require TLS on its
> redirection URI. These properties combined with the possibility that
> the authorization code flow may be used by public clients might open
> more severe attack vectors.
> 
> I think it should be clearly stated that the authorization server MUST
> NOT issue more than one access token per authorization code grant. An
> authorization code should be discarded after its first use and new
> access tokens should only be issued when exchanged for refresh tokens.
> 
> 
> 2. AUTHORIZATION CODE VS. TOKEN?
> 
> Much less important, and please forgive me if this has already been
> discussed, but why isn't the authorization code called an
> authorization token? It is similar to the refresh token in that it can
> be presented in exchange for an access token at the token endpoint. I
> see it as another type of token and wonder if the language used should
> perhaps reflect that as well.
> 
> 
> 3. GRAMMAR CORRECTION IN SECTION 10.12
> 
> In Section 10.12 paragraph three it says "(e.g. a hash of the session
> cookie used to authentication the user-agent)." This should say
> "authenticate" instead of "authentication".
> 
> Regards,
> Andre DeMarre

---

From: André DeMarre <[email-masked]>
Date: Mon, 12 Sep 2011 12:04:48 -0700

I overlooked section 10.5 paragraph 3, which addresses my first point
below, but I think enforcing single use authentication codes should
also be included at the bottom of section 4.1.3 in the "authorization
server MUST" list. Proposed text for item 3: "verify that the
authorization code is valid and has not yet been used to acquire an
access token, and".

It is stated in 10.5 that authorization codes must be short lived, but
it might be good to state that the lifetime of authorization codes
should be included in the authorization server documentation.

Andre DeMarre

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 20 Sep 2011 11:37:54 -0700

> > access tokens should only be issued when exchanged for refresh tokens.

Tweaked the code description slightly:

                REQUIRED. The authorization code generated by the authorization server. The
                authorization code MUST expire shortly after it is issued to mitigate the risk of
                leaks. A maximum authorization code lifetime of 10 minutes is RECOMMENDED. The
                client MUST NOT use the authorization code more than once. If an authorization code
                is used more than once, the authorization server MUST deny the request and SHOULD
                attempt to revoke all tokens previously issued based on that authorization code.
                The authorization code is bound to the client identifier and redirection URI.

> > perhaps reflect that as well.

It's bad enough the refresh token uses 'token'. Adding another 'token' will be too confusing.

> > "authenticate" instead of "authentication".

Thanks,

EHL