| Network Working Group | C. Mortimore, Ed. |
| Internet-Draft | Salesforce |
| Intended status: Standards Track | M.B. Jones |
| Expires: November 01, 2012 | Microsoft |
| B. Campbell | |
| Ping | |
| Y.Y. Goland | |
| Microsoft | |
| May 2, 2012 |
OAuth 2.0 Assertion Profile
draft-ietf-oauth-assertions-03
This specification provides a general framework for the use of assertions as client credentials and/or authorization grants with OAuth 2.0. It includes a generic mechanism for transporting assertions during interactions with a token endpoint, as wells as rules for the content and processing of those assertions. The intent is to provide an enhanced security profile by using derived values such as signatures or HMACs, as well as facilitate the use of OAuth 2.0 in client-server integration scenarios where the end-user may not be present.
This specification only defines abstract message flow and assertion content. Actual use requires implementation of a companion protocol binding specification. Additional profile documents provide standard representations in formats such as SAML and JWT.
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 01, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] .
Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value.
The OAuth 2.0 Authorization Protocol [I-D.ietf-oauth-v2] provides a method for making authenticated HTTP requests to a resource using an access token. Access tokens are issued to clients by an authorization server with the (sometimes implicit) approval of the resource owner. These access tokens are typically obtained by exchanging an authorization grant representing authorization by the resource owner or privileged administrator. Several authorization grant types are defined to support a wide range of client types and user experiences. OAuth also allows for the definition of new extension grant types to support additional clients or to provide a bridge between OAuth and other trust frameworks. Finally, OAuth allows the definition of additional authentication mechanisms to be used by clients when interacting with the authorization server.
In scenarios where security is at a premium one wants to avoid sending secrets across the Internet, even on encrypted connections. Instead one wants to send values derived from the secret that prove to the receiver that the sender is in possession of the secret without actually sending the secret. Typically the way derived values are created is by generating an assertion that is then either HMAC’ed or digitally signed using an agreed upon secret. By validating the HMAC or digital signature on the assertion, the receiver can prove to themselves that the entity that generated the assertion was in possession of the secret without actually communicating the secret directly.
This specification provides a general framework for the use of assertions as client credentials and/or authorization grants with OAuth 2.0. It includes a generic mechanism for transporting assertions during interactions with a token endpoint, as wells as rules for the content and processing of those assertions. The intent is to provide an enhanced security profile by using derived values such as signatures or HMACs, as well as facilitate the use of OAuth 2.0 in client-server integration scenarios where the end-user may not be present.
This specification only defines abstract message flow and assertion content. Actual use requires implementation of a companion protocol binding specification. Additional profile documents provide standard representations in formats such as SAML and JWT.
This specification provides a model for using assertions for authentication of an OAuth client during interactions with an Authorization Server, as well as the use of assertions as authorization grants. It is important to note that the use of assertions for client authentication is orthogonal and separable from using assertions as an authorization grant and can be used either in combination or in isolation. In addition, in scenarios when assertion based authentication and authorization are used in combination, the assertion format and processing may be redundant; under such circumstances, the protocol may be optimized to present a single assertion.
This section defines generic HTTP parameters for transporting assertions during interactions with a token endpoint.
In scenarios where one wants to avoid sending secrets, one wants to send values derived from the secret that prove to the receiver that the sender is in possession of the secret without actually sending the secret.
For example, a client can establish a secret using an out-of-band mechanism with a resource server. As part of this out-of-band communication the client and resource server agree that the client will authenticate itself using an assertion with agreed upon parameters that will be signed by the provisioned secret. Later on, the client might send an access token request to the token endpoint for the resource server that includes an authorization code, as well as a client_assertion that is signed with the previously agreed key and parameters. The client_assertion proves to the token endpoint the identity of the client and the authorization code provides the link to the end-user authorization.
The following section defines the use of assertions as client credentials as an extension of Section 2.3 of OAuth 2.0 [I-D.ietf-oauth-v2]. When using assertions as client credentials, the client includes the assertion and related information using the following HTTP request parameters:
The following non-normative example demonstrates a client authenticating using an assertion during an Authorization Code Access Token Request as defined in Section 4.1.3 of OAuth 2.0 [I-D.ietf-oauth-v2] (with line breaks for display purposes only):
POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code& code=i1WsRn1uB1& client_id=s6BhdRkqt3& client_assertion_type=urn%3Aietf%3Aparams%3Aoauth %3Aclient-assertion-type%3Asaml2-bearer& client_assertion=PHNhbW...[omitted for brevity]...ZT
Token endpoints can differentiate between assertion based credentials and other client credential types by looking for the presence of the client_assertion and client_assertion_type parameters, which will only be present when using assertions for client authentication.
If an assertion is invalid for any reason or if more than one client authentication mechanism is used, the Authorization Server MUST construct an error response as defined in OAuth 2.0 [I-D.ietf-oauth-v2]. The value of the error parameter MUST be the invalid_client error code. The authorization server MAY include additional information regarding the reasons the client assertion was considered invalid using the error_description or error_uri parameters.
For example:
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
{
"error":"invalid_client"
"error_description":"Multiple Credentials Not Allowed"
}
An assertion can be used to request an access token when a client wishes to utilize an existing trust relationship. This may be done through the semantics of (and a digital signature/HMAC calculated over) the assertion, and expressed to the authorization server through an extension authorization grant type. The processes by which authorization is previously granted, and by which the client obtains the assertion prior to exchanging it with the authorization server, are out of scope.
The following defines the use of assertions as authorization grants as an extension of OAuth 2.0 [I-D.ietf-oauth-v2], Section 4.5. When using assertions as authorization grants, the client includes the assertion and related information using the following HTTP request parameters:
The following non-normative example demonstrates an assertion being used as an authorization grant (with line breaks for display purposes only):
POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded client_id=s6BhdRkqt3& grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-bearer& assertion=PHNhbWxwOl...[omitted for brevity]...ZT4
An assertion used in this context is generally a short lived representation of the authorization grant and authorization servers SHOULD NOT issue tokens that exceed that lifetime by a significant period. In practice, that will usually mean that refresh tokens are not issued in response to assertion grant requests and access tokens will be issued with a reasonably limited lifetime. Clients can refresh an expired access token by requesting a new one using the same assertion, if it is still valid, or with a new assertion.
If an assertion is not valid or has expired, the Authorization Server MUST construct an error response as defined in OAuth 2.0 [I-D.ietf-oauth-v2]. The value of the error parameter MUST be the invalid_grant error code. The authorization server MAY include additional information regarding the reasons the assertion was considered invalid using the error_description or error_uri parameters.
For example:
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
{
"error":"invalid_grant",
"error_description":"Audience validation failed"
}
This section provides a general content and processing model for the use of assertions in OAuth 2.0 [I-D.ietf-oauth-v2].
The following are entities and metadata involved in the issuance, exchange and processing of assertions in OAuth 2.0. These are general terms, abstract from any particular assertion format. Mappings of these terms into specific representations are provided by profiles of this specification.
The following are general format and processing rules for the use of assertions in OAuth:
The following clarifies the format and processing rules defined in Section 4 and Section 5 for a number of common use cases:
When a client authenticates to a token service using an assertion, it SHOULD do so according to Section 4.1. The following format and processing rules apply.
The following non-normative example demonstrates the use of a client authentication using an assertion during an Authorization Code Access Token Request as defined in Section 4.1.3 of OAuth 2.0 [I-D.ietf-oauth-v2] (with line breaks for display purposes only):
POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code& code=i1WsRn1uB1& client_id=s6BhdRkqt3& client_assertion_type=urn%3Aietf%3Aparams%3Aoauth %3Aclient-assertion-type%3Asaml2-bearer& client_assertion=PHNhb...[omitted for brevity]...ZT4
When a client is accessing resources on behalf of itself, it SHOULD do so in a manner analogous to the Client Credentials flow defined in Section 4.4 of OAuth 2.0 [I-D.ietf-oauth-v2]. This is a special case that combines both the authentication and authorization grant usage patterns. In this case, the interactions with the authorization server SHOULD be treated as using an assertion for Client Authentication according to Section 4.1, with the addition of a grant_type parameter. The following format and processing rules apply.
The following non-normative example demonstrates the use of a sample assertion being used for a Client Credentials Access Token Request as defined in Section 4.4.2 of OAuth 2.0 [I-D.ietf-oauth-v2] (with line breaks for display purposes only):
POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded client_id=s6BhdRkqt3& grant_type=client_credentials& client_assertion_type=urn%3Aietf%3Aparams%3Aoauth %3Aclient-assertion-type%3Asaml2-bearer& client_assertion=PHNhbW...[omitted for brevity]...ZT
When a client is accessing resources on behalf of a user, it SHOULD be treated as using an assertion as an Authorization Grant according to Section 4.2. The following format and processing rules apply.
The following non-normative example demonstrates the use of a client authenticating using an assertion during an Authorization Code Access Token Request as defined in Section 4.1.3 of OAuth 2.0 [I-D.ietf-oauth-v2] (with line breaks for display purposes only):
POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded client_id=s6BhdRkqt3& grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-bearer& assertion=PHNhbWxwOl...[omitted for brevity]...ZT
When a client is accessing resources on behalf of an anonymous user, the following format and processing rules apply.
Authorization Providers concerned with preventing replay attacks may choose to implement using replay detection using a combination of the Assertion ID and Issued At/Expires At attributes. Previously processed assertions MAY be de-duped and rejected based on the Assertion ID. The addition of the validity window relieves the authorization server from maintaining an infinite state table of processed assertion IDs.
Authorization Servers SHOULD consider the amount of information exposed in error responses, and the risk associated with exposing details of specific processing errors. In addition, Authorization Servers SHOULD prevent timing attacks related to cryptographic processing of the assertion.
There are no additional security considerations beyond those described within OAuth 2.0 [I-D.ietf-oauth-v2], Section 11.
The following is the parameter registration request, as defined in The OAuth Parameters Registry of The OAuth 2.0 Authorization Protocol [I-D.ietf-oauth-v2], for the assertion parameter:
The following is the parameter registration request, as defined in The OAuth Parameters Registry of The OAuth 2.0 Authorization Protocol [I-D.ietf-oauth-v2], for the client_assertion parameter:
The following is the parameter registration request, as defined in The OAuth Parameters Registry of The OAuth 2.0 Authorization Protocol [I-D.ietf-oauth-v2], for the client_assertion_type parameter:
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [I-D.ietf-oauth-v2] | Hammer-Lahav, E, Recordon, D and D Hardt, "The OAuth 2.0 Authorization Framework", Internet-Draft draft-ietf-oauth-v2-26, May 2012. |
The authors wish to thank the following people that have influenced or contributed this specification: Paul Madsen, Eric Sachs, Jian Cai, Tony Nadalin, the authors of OAuth WRAP, and those in the OAuth working group.
[[ to be removed by RFC editor before publication as an RFC ]]
draft-ietf-oauth-assertions-03
draft-ietf-oauth-assertions-02