> -----Original Message----- > From: Marius Scurtescu [mailto:mscurte...@google.com] > Sent: Thursday, June 17, 2010 11:08 AM > To: David Recordon > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user > authorization endpoint > > Yes, I am aware of that thread. I did ask some questions there which are > unanswered.
Please repeat them so we can address them now. > Basically, why cannot be that problem solved by 2 different requests, both > done by the JavaScript layer? > > If latency is a problem, it would be good to know exactly where. I assume > that authorization codes are issued very infrequently. Does this new > token_and_code mode eliminate a transaction every two weeks? > Does that make a difference? The advantage of the user-agent flow is that it address the lack of client authentication with the presence of the end-user. The server might not know who the client really is, but it does know that the right user is sitting in front of the client authorizing the request. It doesn't solve phishing but it provides some security. In the case where a client (native application or user-agent) works in tandem with a server-based component, using just the web-server flow has two disadvantages I'm aware of: the client has to be more complex because it requires callbacks in order to obtain the access token from the server (multiple calls and more complex calls than just a simple server-hosted script), but it also lose the benefit of the user presence for security. The problem is now moved to the communication between the server component and the user-agent component of the client. > Also, when and authorization code is issued I guess it cannot be an > immediate request. If an approval page is shown to the user anyhow, then a > subsequent immediate request to also grab an access token makes no > difference at all. Why not? Both the web-server and user-agent flows were supposed to have immediate mode. > Before we introduce a new complicated profile I think it would be good to > know in very good details what is this solving. For similar requests the > general > response was: "write an extension" or "implement it first". Doesn't that > make sense in this case as well? It makes sense to have a detailed discussion. For similar requests the general response usually came after it was establish that there was enough interest in pursuing it but not enough consensus to put it in the core spec. Let's see where this discussion takes us. Also, this proposal isn't an extension but part of the overall spec flow and architecture. EHL > Marius > > > > On Thu, Jun 17, 2010 at 10:52 AM, David Recordon <record...@gmail.com> > wrote: > > 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=...&s > >>> tate=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
