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 On Fri, Sep 9, 2011 at 4:06 PM, Eran Hammer-Lahav <[email protected]> wrote: > Sending to the right address. > > EHL > > On Sep 9, 2011, at 15:31, "André DeMarre" <[email protected]> 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 > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
