In February, I have posted an article about oauth_wrap mobile webapp profile.
Now that it is unified to OAuth 2.0 drafts, here is another shot:
I have further simplified the flow by talking to Breno and John.
Here it is:
(Fig. XX)
How is that?!
The major difference between Web App Profile is that it creates a request file that captures all the parameters in JSON format at “request_url”. Then, instead of sending parameters over the redirect, it sends this “request_url” over the redirect. The rest is more or less the same.
Here is a suggested text:
3.11 Mobile Web App Flow
The moble web app flow is a user delegation flow suitable for clients
capable of interacting with the end-user’s user-agent (typically a
web browser) that are capability constrained especially for url length
and capable of receiving incoming requests from the
authorization server (capable of acting as an HTTP server).
The mobile web app flow illustrated in figure XX includes following steps.
- The web client creates a request file at a URL “request_url” that captures
all the parameters that it would like to send to the Authorization
Server including client identifier
and a redirect URI to which the authorization server will send
the end-user back once authorization is received (or denied). - The web client initiates the flow by redirecting the end-user’s
user-agent to the end-user endpoint with rul. - The Authorization server obtains parameters by accessing request_url.
- The authorization server authenticates the end-user (via the
user-agent) and establishes whether the end-user grants or
denies the client’s access request. - Assuming the end-user granted access, the authorization server
redirects the user-agent back to the client to the redirection
URI provided earlier. The authorization includes a verification
code for the client to use to obtain an access token. - The client requests an access token from the authorization
server by including its client credentials (identifier and
secret), as well as the verification code received in the
previous step. - The authorization server validates the client credentials and
the verification code and responds back with the access token.
3.11.1 Client Prepares a Request file at request_url
Clients creates and saves the parameters in 3.6.1 at request_url.
This file can be used many times, so it does not need to be done
every time.
3.11.2 Client Requests Authorization
In order for the end-user to grant the client access, the client
sends the end-user to the authorization server. The client
constructs the request URI by adding the following URI query
parameters to the end-user endpoint URI:
- request_url
- Request file url from which the Authorization Server may
obtain the request parameters. - immediate
- OPTIONAL. The parameter value must be set to “true” or
“false”. If set to “true”, the authorization server MUST NOT
prompt the end-user to authenticate or approve access.
Instead, the authorization server attempts to establish the
end-user’s identity via other means (e.g. browser cookies) and
checks if the end-user has previously approved an identical
access request by the same client and if that access grant is
still active. If the authorization server does not support an
immediate check or if it is unable to establish the end-user’s
identity or approval status, it MUST deny the request without
prompting the end-user. Defaults to “false” if omitted
The client directs the end-user to the constructed URI using an HTTP
redirection response, or by other means available to it via the end-
user’s user-agent. The request MUST use the HTTP “GET” method.
For example, the client directs the end-user’s user-agent to make the
following HTTPS requests (line breaks are for display purposes only):
GET /authorize?request_url=hhttps%3A%2F%2Fclient%2Eexample%2Ecom HTTP/1.1
Host: server.example.com
If the client has previously registered a redirection URI with the
authorization server, the authorization server MUST verify that the
redirection URI received matches the registered URI associated with
the client identifier.
The authorization server authenticates the end-user and obtains an
authorization decision (by asking the end-user or establishing
approval via other means). The authorization server sends the end-
user’s user-agent to the provided client redirection URI using an
HTTP redirection response, or by other means available to it via the
end-user’s user-agent.
3.11.1.1. End-user Grants Authorization
Refer to 3.6.1.1.
3.11.1.2 End-user Denis Authorization
Refer to 3.6.1.2
3.11.2. Client Requests Access Token
The client obtains an access token from the authorization server by
making an HTTPS request to the token endpoint. The client
constructs a request URI by adding the following parameters to the
request:
- client_id
- REQUIRED. The client identifier as described in Section 3.1.
- client_secret
- REQUIRED if the client identifier has a matching secret. The
client secret as described in Section 3.1. If it is used, the
request method MUST be “POST”. - code
- REQUIRED. The verification code received from the
authorization server. - secret_type
- PTIONAL. The access token secret type as described by
Section 5.3. If omitted, the authorization server will issue a
bearer token (an access token without a matching secret) as
described by Section 5.2.
The authorization server MUST verify that the verification code,
client identity, client secret, and redirection URI are all valid and
match its stored association. If the request is valid, the
authorization server issues a successful response as described in
Section 3.3.2.1.
If the request is invalid, the authorization server returns an error
response as described in Section 3.3.2.2 with one of the following
error codes:
o “redirect_uri_mismatch”
o “bad_verification_code”
o “incorrect_client_credentials”
Changes
- (2010-05-27) s/rurl/request_url/g