Just in case: I just took the existing oauth-2.0 draft xml and added
mobile web app flow.
Here is the XML snippet for the flow.
<section anchor="mobile_web_app_flow" title="Mobile Web App Flow">
<t>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).</t>
<t>The mobile web app flow includes following steps.</t>
<t>
<list style="format (%C)">
<t>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).</t>
<t>The web client initiates the flow by redirecting the
end-user’s user-agent to the end-user endpoint with
request_url.</t>
<t>The Authorization server obtains parameters by accessing
request_url.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>The authorization server validates the client credentials and
the verification code and responds back with the access token.</t>
</list>
</t>
<section title="Client Prepares a Request file at request_url">
<t>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.</t>
</section>
<section title="Client Requests Authorization">
<t>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:<list hangIndent="6"
style="hanging">
<t hangText="type"><vspace /> REQUIRED. The parameter value MUST
be set to <spanx style="verb">web_server</spanx>.</t>
<t hangText="request_url"><vspace /> REQUIRED. Request file url
from which the Authorization Server may obtain the request
parameters. </t>
<t hangText="immediate"><vspace /> OPTIONAL. The parameter value
must be set to <spanx style="verb">true</spanx> or <spanx
style="verb">false</spanx>. If set to <spanx
style="verb">true</spanx>, 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 <spanx style="verb">false</spanx> if omitted.</t>
</list></t>
<t>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):</t>
<figure>
<preamble>For example, the client directs the end-user's
user-agent to make the following HTTPS requests (line breaks are
for display purposes only):</preamble>
<artwork><![CDATA[
GET /authorize?type=web_server&client_id=s6BhdRkqt3&redirect_uri=
https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
]]></artwork>
</figure>
<t>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.</t>
<t>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.</t>
<section title="End-user Grants Authorization">
<t>Refer to Section 3.6.1.1. </t>
</section>
<section title="End-user Denies Authorization">
<t>Refer to Section 3.6.1.1. </t>
<figure>
<preamble>For example, the authorization server directs the
client to make the following HTTP request:</preamble>
</figure>
<t>The authorization flow concludes unsuccessfully.</t>
</section>
</section>
<section title="Client Requests Access Token">
<t>The client obtains an access token from the authorization server
by making an HTTP <spanx style="verb">POST</spanx> request to the
token endpoint. The client constructs a request URI by adding the
following parameters to the request: <list hangIndent="6"
style="hanging">
<t hangText="type"><vspace /> REQUIRED. The parameter value MUST
be set to <spanx style="verb">web_server</spanx>.</t>
<t hangText="client_id"><vspace /> REQUIRED. The client
identifier as described in <xref target="client_id" />.</t>
<t hangText="client_secret"><vspace /> REQUIRED if the client
identifier has a matching secret. The client secret as described
in <xref target="client_id" />.</t>
<t hangText="code"><vspace /> REQUIRED. The verification code
received from the authorization server.</t>
</list></t>
<t>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
<xref target="access_token_response" />.</t>
<t>If the request is invalid, the authorization server returns an
error response as described in <xref target="token_error" /> with
one of the following error codes: <list style="symbols">
<t>
<spanx style="verb">redirect_uri_mismatch</spanx>
</t>
<t>
<spanx style="verb">bad_verification_code</spanx>
</t>
<t>
<spanx style="verb">incorrect_client_credentials</spanx>
</t>
</list></t>
<figure>
<preamble>For example:</preamble>
<artwork><![CDATA[
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
{
"error":"incorrect_client_credentials"
}
]]></artwork>
</figure>
</section>
</section>
</section>
On Thu, May 27, 2010 at 12:37 PM, David Recordon <[email protected]> wrote:
> This feels exactly like the sort of thing that should be a new flow. Nat,
> thanks for writing it up! I think the next step is getting it into the
> XML2RFC format and some editing.
>
> On Wed, May 26, 2010 at 8:07 PM, Manger, James H
> <[email protected]> wrote:
>>
>> Nat,
>>
>> This looks like a decent idea: allow one user-uri parameter to reference a
>> larger set of user-uri parameters held elsewhere -- to avoid URI size
>> limits.
>>
>> Hopefully it can be specified as another user-uri parameter -- not as a
>> separate flow. It could be helpful for any of the delegation flows.
>>
>> [I think the spec would be improved with a dedicated section on the
>> user-uri (End-User endpoint) that lists all the parameters that it can take
>> (that are defined in the spec) -- and explains each parameter (some will
>> need their own sub-section). The per-flow sections would not repeat any of
>> that: they could be a lot more succinct.]
>>
>>
>> Quick suggestion for text:
>>
>> [for section 3.2 "End-user Endpoint"]
>> ...
>> The following user-uri parameters are defined in this specification:
>> ...
>> inc_uri A URI for obtaining further parameters for this request.
>>
>> ...
>> <inc_uri> allows parameters for the user-uri request to be referenced,
>> instead of included directly. This is particularly helpful when the
>> parameters are large and might not fit within the URI length limits of the
>> user's browser. The response to a GET request to <inc_uri> SHALL be user-uri
>> parameters in XXX format. Any parameter appearing directly in the user-uri
>> SHALL override the same parameter obtained from <inc_uri>. The <inc_uri>
>> response SHOULD be cacheable by including appropriate HTTP cache-control
>> headers. The <inc_uri> SHALL be an HTTP or HTTPS URI, and SHOULD be the
>> latter.
>>
>>
>> [Probably need a way for a service to indicate whether or not it supports
>> <inc_uri>. Perhaps a "features=inc_uri,other" parameter in the HTTP
>> WWW-Authenticate header.]
>>
>> --
>> James Manger
>>
>>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf Of
>> Nat Sakimura
>> Sent: Wednesday, 26 May 2010 11:58 PM
>> To: oauth
>> Subject: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow
>>
>> Back in February, I have suggested mobile web app flow to the oauth_wrap
>> group.
>> Now that it is wrapped into OAuth 2.0, here is my another try, this
>> time for OAuth 2.0 draft.
>>
>> "OAuth 2.0 Mobile WebApp Flow"
>> http://www.sakimura.org/en/modules/wordpress/oauth-20-mobile-webapp-flow/
>>
>> I really wish that this could be included in OAuth 2.0 as it will help
>> build identity layers on OAuth 2.0 that works for mobile web browsers etc.
>>
>> --
>> Nat Sakimura (=nat)
>> http://www.sakimura.org/en/
>> http://twitter.com/_nat_en
>> _______________________________________________
>> OAuth mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
