Hey Marius, take a look at http://www.ietf.org/mail-archive/web/oauth/current/msg02657.html from Twitter.
On Thu, Jun 17, 2010 at 10:48 AM, Marius Scurtescu <mscurte...@google.com> wrote: > 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
