.Nat Zone

Digital Identity et al.

OAuth 2.0 Mobile WebApp Flow


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.

  1. 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).
  2. The web client initiates the flow by redirecting the end-user’s
    user-agent to the end-user endpoint with rul.
  3. The Authorization server obtains parameters by accessing request_url.
  4. 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.
  5. 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.
  6. 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.
  7. 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 file url from which the Authorization Server may
obtain the request parameters.
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. End-user Grants Authorization

Refer to End-user Denis Authorization

Refer to

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

REQUIRED. The client identifier as described in Section 3.1.
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”.
REQUIRED. The verification code received from the
authorization server.
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

If the request is invalid, the authorization server returns an error
response as described in Section with one of the following
error codes:

o “redirect_uri_mismatch”

o “bad_verification_code”

o “incorrect_client_credentials”


  • (2010-05-27) s/rurl/request_url/g

 - identity