Just getting a chance to review this – I apologize for not getting this before
the meeting started.
We’d like to see some form of an Assertion Profile, similar to section 5.2 from
draft-hardt-oauth-01. We have strong customer use-cases for an assertion
based flow, specifically SAML bearer tokens, and I believe Microsoft may have
already shipped a minor variation on this ( wrap_SAML ) in Azure.
Here’s a rough stab – hopefully others interested in this profile can comment.
---------------------------------------------
Assertion Flow
This flow is used when the client wishes to exchange an existing security token
or assertion for an oauth_access_token. This flow is suitable when the
client is acting on behalf of either itself or the end-user, it is not possible
to use one of the end-user authorized flows, and a password based profile is
not desirable.
Prior to making a request using this flow, the client MUST have obtained a
client identifier, and established a means for obtaining an assertion to be
presented to the authorization server. Both the assertion formats, the method
for obtaining those assertions, and the method of validating those assertions
are beyond the scope of this specification.
The client constructs an HTTP "POST" request to the access token request
endpoint and includes the following REQUIRED parameters:
oauth_mode
The parameter value MUST be set to "flow_assertion" (case sensitive).
oauth_client_identifier
The client identifier.
oauth_assertion_format
The assertion format – likely a normative URI, for instance:
urn:oasis:names:tc:SAML:2.0:cm:bearer
oauth_assertion
<assertion> - b64 encoded
The client MAY also include the following OPTIONAL parameters as well as any
additional parameters as defined by the authorization server:
oauth_scope
If the authorization server has defined a manner for the client to
request certain capabilities of the access token, this parameter SHOULD be used
to do so.
For example, the client makes the following HTTPS request:
POST /access_token HTTP/1.1
Host: server.example.com
oauth_mode=flow_assertion&oauth_client_identifier=s6BhdRkqt3&
oauth_assertion_format= urn:oasis:names:tc:SAML:2.0:cm:bearer&
oauth_assertion=<base64 encoded saml>
The authorization server MUST verify that the presented assertion is valid and
derive the resource owner. The authorization server MAY verify that the client
is authorized to use this flow. If the request is authorized, the access token
is included in the HTTP response body using the
"application/x-www-form-urlencoded" content type as defined by
[W3C.REC‑html40‑19980424] (Ragget, D., Ed., Le Hors, A., Ed., and I. Jacobs,
Ed., “HTML 4.0 Specification,” .) with a 200 status code (OK).
The response contains the following REQUIRED parameter:
oauth_access_token
The access token.
The authorization server MAY also include the following parameters:
oauth_expires
The lifetime of the access token in seconds.
oauth_refresh_token
The refresh token.
For example:
HTTP/1.1 200 OK
Content-Type: application/x-www-form-urlencoded
oauth_access_token=FJQbwq9OD8&oauth_refresh_token=gO3CHNqpH8
The authorization server must retain the scope, duration, and other attributes
approved by the resource owner, and enforce these restrictions when receiving a
client request made with the tokens issued.
Once the client receives and stores the token credentials, it can proceed to
access protected resources on behalf of the resource owner by making
authenticated requests (Section 4 (Accessing a Protected Resource)) using the
access token received.
If the request fails verification, the authorization server SHOULD respond with
the appropriate HTTP response status code. The authorization server MAY include
further details about why the request was rejected in the response body.
For example:
HTTP/1.1 401 Authorization Required
WWW-Authenticate: OAuth realm="example"
---------------
Also, your examples of the initial post in 2.4 and 2.5 seem to be missing the
oauth_mode parameter.
Thanks for your work here!
-cmort
On 3/19/10 6:28 PM, "David Recordon" <davidrecor...@facebook.com> wrote:
As I mentioned a few weeks ago [1], I started working on editing the first
draft of OAuth 2.0 over the past two weeks. While I realize that it's 6pm
Friday (sorry about that), I hope to have a solid discussion about it at
Monday's meeting. You can find the current draft of it – plus all of the
document history – on my public GitHub account a
thttp://github.com/daveman692/OAuth-2.0. Eran will be doing an initial editing
pass before Monday and then spend more time with it next week.
I've attached both a HTML and TXT copy to this email and plan to officially
submit it as an Internet Draft.
The following are highlighted changes from draft-hardt-oauth-01:
1. A Web Client flow designed for use within JavaScript. It also
supports the use cases of the rich app profile so that they're
not two separate flows.
2. A new device flows which is based on the Netflix/Tivo flow (TV
shows you a code that you type in on your computer).
http://www.ietf.org/mail-archive/web/oauth/current/msg01346.html
3. Remove captchas from the username/password flow. They haven't
been successfully implemented within this context and create
complexity especially when we use other signals to detect
compromised accounts.
http://www.ietf.org/mail-archive/web/oauth/current/msg01293.html
4. Don't allow bearer tokens without either SSL and/or signatures.
While some providers may offer this ability, they should be out
of spec for doing so though technically it won't break the flows.
5. Abstract the refresh token flow out of each profile into its own
section. Support the ability to request access token secrets
when refreshing.
6. Support signatures for making API requests but not for getting
access tokens. If you want to use signatures, you'll get an
access token and then make a refresh call where you ask for a
token secret. This causes the auth server to mark the token as
no longer being valid as a bearer token via SSL. This
performance tradeoff seems realistic given many use cases focus
on high-volume API transactions and thus the one additional
request at the onset should be noise. The signature mechanism is
currently from OAuth 1.0.
Obviously I couldn't have made so much progress so quickly if it weren't for
WRAP and I hope that 2.0 both addresses the WRAP use cases as well as those we
all have been discussing here. I hope that I haven't missed anyone who
contributed to prior work and am happy to add other authors if I have (and they
wish to be added)!
Thanks,
--David
[1] http://www.ietf.org/mail-archive/web/oauth/current/msg01225.html
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
