On Mon, Jan 10, 2011 at 3:22 PM, Phil Hunt <phil.h...@oracle.com> wrote: > What about the idea that the code is only used as a hand-off mechanism > between service components (e.g. authorization manager vs, resource access > manager). In that case, the code would not be usable for anything except to > get an access token (which still requires client auth). A code might have a > very short expiration period with a limited number of uses (e.g. ONE).
I believe that is the case already for all of the uses of the verification code in the spec. IIRC, we settled on something where the authorization code MUST have a short-lifetime, and SHOULD be single-use. Exchanging the authorization code for the refresh token MUST require client auth. The user-agent profile usage of the authorization code should not be any different than the rest of the spec. > The frames timing issue is interesting, but doesn't it suggest a profile > where the whole code step is bypassed (e.g. by receiving code and token)? The user-agent profile callback URL should end up looking like this: /callback#code=<code>&token=<token> The token component is there so immediately return a usable access token to the relying party/client server. The code component is there so the server-side components of the RP can obtain a refresh token and additional access tokens. > In general I perceive a code as being relatively simple (e.g. like an > artifact), short lived, and having almost no rights (except to obtain a an > access/refresh token). It is very, very similar to the SAML artifact. I think the only major difference is that the SAML specs require a pre-configured return-to URL for artifacts. The OAuth2 spec allows for more dynamic return-to URL settings by having the RP server present the actual callback URL when it presents the artifact, and having the IdP check that the callback URL matches the artifact. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
