Shifting from client type profile names to flow type profiles sounds good. Not too sure about the combined case, token_and_code. I am not opposed to it, but I think it would help us wrap our heads around it if a detailed use case was presented.
Thanks, Marius On Wed, Jun 16, 2010 at 11:05 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > This is a joint proposal from David Recordon and me: > > ** Background: > > The latest draft (-08) unified the web-server and user-agent client types > into a single authorization request format. This was done because once we > added an optional authorization code to the user-agent response, it became > almost identical to the web-server call. The two remaining differences: > > - The web-server response must not return an access token, only an > authorization code. > - The web-server response uses the URI query while the user-agent response > uses the URI fragment. > > The way in which the client indicates which response is requests is by using > the 'type' parameter with either 'web_server' or 'user-agent'. This is all > documented in: > > http://tools.ietf.org/html/draft-ietf-oauth-v2-08#section-3 > > Many (if not most) services are likely to implement both the user-agent and > web-server types (based on existing deployment and the requirements expressed > by many of the participants). > > The web-server flow requires client authentication (client secret) in order > to obtain an access token. It also enables the registration of a redirection > URI. > > When using the user-agent flow, the client does not authenticate with the > authorization server (at all) to obtain an access token. However, it does > need to authenticate if it wants to exchange the optional authorization code > for (another) access token. > > The authorization server has a few options when managing the security and > trust implications of each request type: > > - Require that the client provide its type when registering with the service > - if the authorization server knows the client type, it can limit that client > to only make requests suitable for that client type, as well as only issue a > client secret when the client is not a user-agent. > > - Issue different access tokens based on the security context in which they > are obtained - access tokens issued using the direct user-agent request will > provide less access (shorter duration, read only, etc.) than an access token > obtained using the web-server request type. > > The first approach is problematic for complex clients requesting both an > access token and authorization code using the user-agent request type. In > this case, the authorization server is issuing two access tokens, each using > a different level of security. It is means that one developer will need to > obtain a different client identifier for the same application across > different platforms. > > The current separation between the two request types (user-agent and > web-server) seems artificial. This is especially true when considering the > use cases for native applications and the applicability of both options. At > the end, the client type doesn't matter. What matters is whether the access > token is issued with or without client authentication (and whether that > authentication can be trusted, which goes beyond what the protocol can > provide). > > ** Proposal: > > Replace the 'type' parameter with a new parameter called 'request' (working > title) which can take one of three values: 'token', 'code', or > 'token_and_code'. This will allow the client (regardless of its type) to > explicitly say what it wants. > > The response is sent as follows: > > - If the client requests an access token, all the response parameters > (including errors) are included in the fragment (same as the user-agent flow > today). > - If the client requests an authorization code, all the parameters are > included in the query (same as the web server flow today). > - If the client requests both, the 'code', 'status', and 'error' are included > in the query while everything else is included in the fragment (explained in > the example below). > > The authorization server issues the appropriate user warnings and access > token based on the authentication level obtained. For example, when issuing > an access token the server has to consider: > > - Was the client authenticated using a secret or other means? > - Was the redirection URI registered? > - Is this a known client (white list) from a trusted third party (they are > known not to leak their secrets)? > > The advantage of this approach is that it more clearly frames the security > context of issuing tokens. It puts native applications at the same level as > the web-server and user-agent clients (no one gets a special parameter value). > > ** Examples: > > To help show the similarities, here are three example requests and responses: > > - Token only (aka user-agent): > > https://server.example.com/oauth/authorize? > client_id=...& > redirect_uri=http://client.example.com/callback&; > request=token& > state=foo > > http://client.example.com/callback#access_token=...&expires_in=...&state=foo > > In this case all of the parameters are in relation to the token and thus > consumed directly by the JavaScript, desktop app, etc. > > - Code only (aka web-server): > > https://server.example.com/oauth/authorize? > client_id=...& > redirect_uri=http://client.example.com/callback&; > request=code& > state=foo > > http://client.example.com/callback.php?code=...&state=foo > > In this case there isn't an access token and all of the parameters are > consumed by the client's server to be traded for an access token via a HTTPS > request to the AS. > > - Token and code: > > https://server.example.com/oauth/authorize? > client_id=...& > redirect_uri=http://client.example.com/callback&; > request=token_and_code& > state=foo > > http://client.example.com/callback.php?code=...&state=foo#access_token=...&expires_in=... > > In this case the parameters are consumer both by the JavaScript and the > client's server. The parameters about the access token are in the fragment. > The code is a query parameter so that the server can access it. state and > error are useful to both and thus are query parameters which can be accessed > by the JavaScript and the server. > > > _______________________________________________ > 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
