What do you mean by valid data? In the user-agent case, the server returns an access token. We added an optional authorization code which can only be used after exchanging it for an access token with required client authentication (client secret).
EHL -----Original Message----- From: Justin Richer [mailto:[email protected]] Sent: Thursday, June 17, 2010 11:05 AM To: Marius Scurtescu Cc: Eran Hammer-Lahav; OAuth WG ([email protected]) Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint I think I'm missing something on the combined case here. How does the server trust the javascript client code to pass it back valid data? Is it assumed to just rely on an established browser session at that point that the javascript client has access to? -- Justin On Thu, 2010-06-17 at 13:48 -0400, Marius Scurtescu 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 <[email protected]> > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
