[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
Revived interest in OAuth's SAML Assertion profile -------- Original Message --------
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" <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. |
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]