> On Sep 9, 2011, at 15:31, "André DeMarre" <andredema...@gmail.com>
> 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.
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.
> > 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.
It's bad enough the refresh token uses 'token'. Adding another 'token' will be
too confusing.
> > 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".
Thanks,
EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
