OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Fwd: Re: [OAUTH-WG] First draft of OAuth 2.0

Title: Re: [OAUTH-WG] First draft of OAuth 2.0
Revived interest in OAuth's SAML Assertion profile

-------- Original Message --------
Subject: Re: [OAUTH-WG] First draft of OAuth 2.0
Date: Tue, 23 Mar 2010 01:09:59 -0700
From: Chuck Mortimore <cmortimore@salesforce.com>
To: David Recordon <davidrecordon@facebook.com>, OAuth WG <oauth@ietf.org>

Re: [OAUTH-WG] First draft of OAuth 2.0 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:

        The parameter value MUST be set to "flow_assertion" (case sensitive).
        The client identifier.
        The assertion format – likely a normative URI, for instance: urn:oasis:names:tc:SAML:2.0:cm:bearer
        <assertion> - b64 encoded

The client MAY also include the following OPTIONAL parameters as well as any additional parameters as defined by the authorization server:

        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:

        The access token.

The authorization server MAY also include the following parameters:

        The lifetime of the access token in seconds.
        The refresh token.

For example:

    HTTP/1.1 200 OK
    Content-Type: application/x-www-form-urlencoded


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!


On 3/19/10 6:28 PM, "David Recordon" <davidrecordon@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).
   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.
   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)!


[1] http://www.ietf.org/mail-archive/web/oauth/current/msg01225.html

OAuth mailing list

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]