TOC 
Network Working GroupN. Sakimura
Internet-DraftNRI
Intended status: ExperimentalJ. Bradley
Expires: January 6, 2012Protiviti Government Services
 M. Jones
 Microsoft
 B. de Medeiros
 Google
 C. Mortimore
 Salesforce
 E. Jay
 MGI1
 July 5, 2011


OpenID Connect Framework 1.0 - draft 01
openid-connect-framework-1_0.xml

Abstract

This document describes the more advanced request and response formats for OpenID Connect.

Requirements Language

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 RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Status of this Memo

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 January 6, 2012.

Copyright Notice

Copyright (c) 2011 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.



Table of Contents

1.  Introduction
2.  Terminology
3.  Authorization Endpoint
    3.1.  Authorization Request
        3.1.1.  OpenID Request Object
    3.2.  Authorization Response
    3.3.  Authorization Error Response
        3.3.1.  Error Codes
4.  UserInfo Endpoint
    4.1.  Normal Claims
    4.2.  Aggregated and Distributed Claims
    4.3.  Requests
    4.4.  Responses
        4.4.1.  Example Responses
    4.5.  Errors
5.  Introspection Endpoint
    5.1.  Error Codes
6.  Signatures
7.  Encryption
8.  Verification
    8.1.  Authorization Request Verification
    8.2.  Authorization Response Verification
    8.3.  UserInfo Request Verification
    8.4.  UserInfo Response Verification
9.  Other Items for Consideration
10.  IANA Considerations
11.  Security Considerations
    11.1.  Assertion Manufacture/Modification
    11.2.  Assertion Disclosure
    11.3.  Assertion Repudiation
    11.4.  Assertion Redirect
    11.5.  Assertion Reuse
    11.6.  Secondary Authenticator Manufacture
    11.7.  Secondary Authenticator Capture
    11.8.  Assertion Substitution
    11.9.  Authentication Request Disclosure
    11.10.  Timing Attack
    11.11.  Authentication Process Threats
12.  Normative References
Appendix A.  Acknowledgements
Appendix B.  Document History
§  Authors' Addresses




 TOC 

1.  Introduction

OpenID Connect Core defines the basic requests and responses in allow easy and simple implementations and conformance. This specification defines various optional parts of OpenID Connect that uses more complex requests and responses.



 TOC 

2.  Terminology

In addition to the terminology defined in the OpenID Core (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011.) [OpenID.CC] specification, the following terms are defined:

Identity Provider
Authorization Servers that are able to support OpenID Connect Messages.
Claims Provider
Authorization Servers that can return claims about a user.


 TOC 

3.  Authorization Endpoint

This specification introduces some new parameters to the OpenID Connect Core (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011.) [OpenID.CC] Authorization Request.



 TOC 

3.1.  Authorization Request

Section 4.1.1 and 4.2.1 of OAuth 2.0 (Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2.0] defines OAuth Authorization Request parameters.

The following extension parameters are defined:

request
OPTIONAL. A JWT (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” March 2011.) [JWT] encoded OpenID Request Object (OpenID Request Object).
request_uri
OPTIONAL. A URL that points to the OpenID Request Object.
display
OPTIONAL. A string value that specifies how the authorization server displays the authentication page to the user.
none
The authorization server MUST NOT display any authentication page.
popup
The authorization server displays a popup authentication page.
mobile
The authorization server performs authentication using a mobile device???
prompt
OPTIONAL. A space delimited, case sensitive list of string values that specifies how the authorization server prompts the user for reauthentication and reapproval. The possible values are:
login
The authorization server MUST prompt the user for reauthentication.
consent
The authorization server MUST prompt the user for reapproval before returning information to the client.
select_account
The authorization server MUST prompt the user to select a user account if the current account does not match the account in the request.

Following is a non-normative example when they are sent in the query parameters serialization.

GET /authorize?scope=openid&response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&request=HeADeR.pAyl0rd.cRypT0
&prompt=login
&display=popup
HTTP/1.1
Host: server.example.com



 TOC 

3.1.1.  OpenID Request Object

The OpenID Request object is used to provide OpenID request parameters that MAY differ from the default ones. Implementing support for the OpenID Request object is OPTIONAL. Supporting it is necessary for implementations that need to request or provide sets of claims other than the default UserInfo claim set, as defined in the OpenID UserInfo Endpoint (Sakimura, N., Bradley, J., de Medeiros, B., and M. Jones, “OpenID Connect UserInfo Endpoint 1.0,” June 2011.) [UserInfo.Endpoint] specification.

If present, the OpenID Request object is passed as the value of a "request" OAuth 2.0 parameter and is represented as a JWT. Parameters that affect the information returned from the UserInfo Endpoint are in the "inf" member. Parameters that affect the information returned in an ID Token are in the "idt" member. If the same parameters are available both as query strings and in the OpenID Request Object, the later takes the precedence.

An example an OpenID request object is as follows:

{
 "inf":
   {
     "clm":
       {
         "name": null,
         "nickname": {"opt": true},
         "email": null,
         "verified": null,
         "picture": {"opt": true},
       },
     "fmt": "sig"
   }
 "idt":
   {
     "clm":
       {
        "aat": null
       }
     "mxa": 86400,
     "eaa": "2"
   }
}

The OpenID Request object is a JWT (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” March 2011.) [JWT] that MAY contain a set of members defined by this specification and MAY contain other members that are not defined by this specification. The JWT MAY be signed or unsigned. When it is unsigned, it will be indicated by the JWT "sig":"none" convention in the JWT header.

The members defined by this specification are:

inf
OPTIONAL. (UserInfo Endpoint request): Requests affecting the values to be returned from the UserInfo Endpoint. If not present, the UserInfo Endpoint behaves in the default manner.
idt
OPTIONAL. (ID request): Requests affecting the values to be included in the Session Token. If not present, the default ID Token contents are used. If present, these parameters are used to request deltas to the default contents of the Session Token.

If signed, the OpenID Request object SHOULD contain the standard JWT "iss" and "aud" claims.

The structure of the "inf" (UserInfo Endpoint request) member is a JSON object that MAY contain the following members:

clm
OPTIONAL. (Requested Claims): Set of requested claims from the UserInfo Endpoint. If not present, the default UserInfo claims held by the IdP are returned.
fmt
OPTIONAL. (Format): The requested format for the UserInfo Endpoint information. If not present, the format is an unsigned JSON object.
loc
OPTIONAL. (Locale): The default languages and scripts of the entire claim request, represented as a space-separated list of BCP47 (Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.) [RFC5646] language tags.

The "clm" member is a JSON object with a member for each requested claim. The member names are the requested claim names. The member values may be either:

null
This indicates that this claim is being requested in the default manner. In particular, this is a required claim. OR
A JSON Object
This is used to provide additional information about the claim being requested.

The claims MAY be represented in multiple languages and scripts. To specify languages and scripts for the claim request, BCP47 (Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.) [RFC5646] language tags delimited by a "#" MUST be added to each requested claim name for which a particular language and script is requested. For example, the claim family_name#ja-Kana-JP is used for expressing Family Name in Katakana in Japanese, which is commonly used to index and represent the phonetics of the Kanji representation of the same value represented as family_name#ja-Hani-JP.

All members of the "clm" object are OPTIONAL.

The members of the JSON object value following a claim name defined by this specification are:

opt
If this is an optional claim, this member's value MUST be true, else, if present, its value MUST be false, which indicates that it is a required claim. If it is not present, it is a required claim.

Other members MAY be defined to provide additional information about the requested claim. If the "clm" member is present in the "inf" object, the claims requested within it override the default claim set that would otherwise be returned from the UserInfo Endpoint.

The "fmt" member of the "inf" object is used to specify the requested format of the UserInfo Endpoint contents. Values defined are:

nor
(normal) - in which case the contents are an unsigned JSON object
sig
(signed) - in which case the contents are a signed JWT
enc
(encrypted) - in which case the contents are an signed and encrypted JWT

All members of the "inf" object are OPTIONAL. Other members MAY be present and if so, SHOULD understood by both parties.

The structure and function of the "idt" (ID Token request) member of the OpenID Request object is similar to that of the "inf" member. It also contains an optional "clm" member, with the same structure as that for the "inf" member. If the "clm" member is present in the "idt" object, the claims requested within it modify the default claim set that would otherwise be returned in the ID Token. Unlike for the "inf" member, typically these claims will augment, rather than override the default set.

Following claim MAY be requested in the ID Token by specifying it in the "clm" member:

aat
OPTIONAL. (authenticated at): Requests that the "aat" claim be present. The claim value is the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time that the user authentication occurred. (The "aat" claim semantically corresponds to the openid.pape.auth_time response parameter.)

In addition to the "clm" member, this additional member is defined within the "idt" member of the OpenID Request object:

mxa
OPTIONAL. (max authentication age): Specifies that the user must be actively authenticated if any present authentication is older than the specified number of seconds. (The "mxa" request parameter corresponds to the OpenID 2.0 openid.pape.max_auth_age request parameter.)
eaa
OPTIONAL. (entity authentication assurance): Specifies the X.eaa / ISO/IEC29115 (McCallister, E., “ITU-T Recommendation X.eaa | ISO/IEC 2nd CD 29115 -- Information technology – Security techniques – Entity authentication assurance framework,” .) [ISO29115] entity authentication assurance level that is requested by the client.

It is anticipated that additional "idt" parameters MAY be defined to request that additional properties hold for the authentication - for instance, that certain authentication policies be applied (in the same spirit of the OpenID 2.0 openid.pape.auth_policies values), or that the authentication conform to the policies defined by a specified trust framework. These parameters MAY be defined by extension specifications.

All members of the "idt" object are OPTIONAL. Other members MAY be present and if so, SHOULD understood by both parties.

All members of the OpenID Request object are OPTIONAL. Other members MAY be present and if so, SHOULD be understood by both parties.



 TOC 

3.2.  Authorization Response

Authorization responses are defined in section 4.1.2 of the OpenID Connect Core (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011.) [OpenID.CC] specification.



 TOC 

3.3.  Authorization Error Response

If the end-user denies the access request or if the request fails, the authorization server informs the client by returning parameters defined in section 4.1.2.1 of OAuth 2.0 (Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2.0] .



 TOC 

3.3.1.  Error Codes

In addition to the error codes defined in section 4.1.2.1 of OAuth 2.0 (Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2.0], this specification defines the following additional error codes:

login_required
The authorization server requires user authentication.
session_selection_required
The user is required to select a session at the authorization server.
approval_required
The authorization server requires user approval.
user_mismatched
The current logged in user at the authorization server does not match the requested user.



 TOC 

4.  UserInfo Endpoint

The UserInfo Endpoint returns claims for the authenticated user. There are three different types of claims.

Normal Claims
Claims that are directly asserted by the Identity Provider.
Aggregated Claims
Claims that are asserted by a claims provider other than the Identity Provider but are returned by Identity Provider.
Distributed Claims
Claims that are asserted by a claims provider other than the Identity Provider but are returned as references by the Identity Provider.

The UserInfo Endpoint MUST support normal claims.

Aggregated and distributed claims support is OPTIONAL.

Claim objects contain members and member values which are the individual claims and claims values. A claim object is represented by a JSON object which contains a collection of name/value pairs for the claims.



 TOC 

4.1.  Normal Claims

Normal claims are represented as members in a claims object. The claim name is the member name and the claim value is the member value.



 TOC 

4.2.  Aggregated and Distributed Claims

Aggregated and distributed claims are represented within the "_claim_names" and "_claim_sources" members of the claims object.

_claim_names
This is a JSON object whose member names are the claims names for the aggregated and distributed claims. The member values are references to the member names in the "_claim_sources" member of the claim object from which the actual value can be retrieved.
__claim_sources
This is a JSON object whose member names are referenced by the member values of the "_claim_names" member of the claim object. The member values contain sets of aggregated claims or reference locations for distributed claims. The member values can have one of the following formats depending on whether they're storing aggregated claims or distributed claims:
Aggregated Claims
A JSON object which MUST contain the "JWT" member whose value is a JWT (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” March 2011.) [JWT] which MUST contain all the claims in the "_claim_names" object which references the corresponding "_claim_sources" member. Other members MAY be present if they are understood by both parties.
JWT
REQUIRED. JWT Value
Distributed Claims
A JSON object which contains the following members and values:
endpoint
REQUIRED. The value is the OAuth 2.0 resource endpoint from which the associated claim can be retrieved. The endpoint URL MUST return the claim as a JWT.
access_token
OPTIONAL. Access token enabling retrieval of the claims from the endpoint URL by using the OAuth 2.0 BEARER (Jones, M., Hardt, D., and D. Recordon, “OAuth 2.0 Protocol: Bearer Tokens,” June 2011.) [Bearer_Tokens] scheme. Claims SHOULD be requested using the Authorization request header field and claims sources MUST support this method.
Other members MAY be present, if understood by both parties



 TOC 

4.3.  Requests

Clients MAY send requests with the following parameters to the UserInfo Endpoint to obtain further information about the user.

access_token
REQUIRED. The access_token obtained from an OpenID Connect authorization request.
schema
OPTIONAL. The schema in which the data is to be returned. The only predefined value is openid. If this parameter is not included, the response may be a proprietary format to support backwards compatibility. A URL may be passed to define custom schemes not specified by short names. Custom scheme names and responses are out of scope for this specification.
id
RESERVED. This is reserved for backwards compatibility. It MUST be ignored by the endpoint if the "openid" schema is used.


 TOC 

4.4.  Responses

If the requested schema is openid, the response MUST return a plain text JSON object which contains a set of requested claims. Following the Portable Contacts draft specification, claim values can be simple strings, boolean values containing the strings "true" or "false", or complex values which contain child attributes and their values. In addition, claims can be singular or plural values. Plural values contain multiple complex values which contain the "value" and optional "type" and "primary" attributes.

The UserInfo endpoint MUST return claims in JSON format unless a request for a different format is made by the client in the Authorization request. The UserInfo endpoint MAY return claims in JWT format which can be signed or encrypted via JWS (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.) [JWS] and JWE (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Encryption,” March 2011.) [JWE] respectively. See the OpenID Connect Core (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011.) [OpenID.CC] specification on how to request a different format. The UserInfo Endpoint MUST return a content-type header to indicate which format is being returned. The following are accepted content types:

Content-TypeFormat Returned
application/json plain text JSON object
application/jwt A JWT



 TOC 

4.4.1.  Example Responses

The following is a non-normative normal claims responses:

{
 "name": "Jane Doe"
 "given_name": "Jane",
 "family_name": "Doe",
 "email": "janedoe@example.com",
 "picture": "http://example.com/janedoe/me.jpg"
}

The following is a non-normative claims response containing aggregated and distributed claims:

{
 "name": "Jane Doe"
 "given_name": "Jane",
 "family_name": "Doe",
 "email": "janedoe@example.com",
 "picture": "http://example.com/janedoe/me.jpg"
 "_claim_names": {
   "birthday": "src1",
   "eye_color": "src1",
   "payment_info": "src2",
   "shipping_address": "src2",
   "credit_score": "src3"
  },
 "_claim_sources": {
   "src1": {"JWT": "JWT_hdr.JWT_claims.JWT_crypto"},
   "src2": {"endpoint": "https://merchant.example.com/claimsource"},
   "src3": {"endpoint": "https://creditagency.example.com/claimshere", "access_token": "ksj3n283dke"}
  }
}



 TOC 

4.5.  Errors

In addition to the error codes defined in section 4.1.2.1 of OAuth 2.0 (Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2.0], this specification defines the following additional error codes:

invalid_access_token
The access token is not valid for the requested resource, malformed, is in an incorrect format, outside the valid scope, or expired.
invalid_schema
The requested schema is invalid or unsupported.


 TOC 

5.  Introspection Endpoint

The introspection endpoint returns a text JSON object which contains information about the end user associated with supplied access or ID token. It is for use by clients that cannot or do not wish to handle signed tokens.

Request Parameters: One of the following parameters

access_token
OPTIONAL. A token obtained from the token endpoint.
id_token
OPTIONAL. An ID token obtained from the authorization request.

Both parameters are optional, but at least one parameter MUST be supplied.

Response:

The response is a text JSON object of an ID token using the "application/json" media type. If the request contains access token, the authorization server creates a version of an ID token and returns it as a JSON object. However, a session is not created. If the request contains id_token, then the server returns the text JSON object of the ID token.

The following is a non-normative example of a request to the introspection endpoint:

Request:

GET /op/introspection?access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6
ImNsaWVudC5leGFtcGxlLmNvbSJ9.eyJpc3N1ZXIiOiJodHRwOlwvXC9zZXJ2ZXIuZXhhbXBs
ZS5jb20iLCJjbGllbnRfaWQiOiJjbGllbnQuZXhhbXBsZS5jb20iLCJhdWRpZW5jZSI6ImNsa
WVudC5leGFtcGxlLmNvbSIsImlkIjoidXNlcl8yMzQyMzQiLCJleHAiOjEzMDM4NTI4ODB9.a
JwagC6501Da-zK-X8Az9B-Y625aSEfxVuBpFEDjOxQ
Host: server.example.com

Response:

HTTP/1.1 200 OK
Content-Type: application/json

{
"issuer": "http://server.example.com",
"client_id": "http://client.example.net",
"user_id": "Jane Doe",
"aud": "http://client.example.net",
"exp": "1236485123"
}



 TOC 

5.1.  Error Codes

In addition to the error codes defined in Section 5.2 of OAuth 2.0 (Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2.0], this specification defines the following error codes.

invalid_access_token
The access token is not valid for the requested resource, malformed, is in an incorrect format, outside the valid scope, or expired.
invalid_id_token
The ID token is not valid for the requested resource, malformed, is in an incorrect format, or expired.


 TOC 

6.  Signatures

Depending on the transport through which the messages are sent, the integrity of the message may not be guaranteed and the originator of the message may not be authenticated. To mitigate these risks, OpenID Connect utilizes JSON Web Signatures (JWS) (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.) [JWS].

Following is the parameters for JWT.

typ
OPTIONAL. One of "JWT", "openid2json+sig".
alg
REQUIRED. One of the algorithm values specified in Table 3 of JWS (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.) [JWS]

Compact Serialization SHOULD BE used when passing it through query parameters, while JSON serialization SHOULD BE used when returning it in HTTP Body.

Following is a non-normative example of such signature in Compact serialization, where HS256 algorithm was used (with line breaks for display purposes only):

eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk



 TOC 

7.  Encryption

To achieve message confidentiality and audience restriction, OpenID Connect uses JSON Web Encryption (JWE) (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Encryption,” March 2011.) [JWE].



 TOC 

8.  Verification



 TOC 

8.1.  Authorization Request Verification

If the request was signed, the Server MUST verify the signature as in JWT.



 TOC 

8.2.  Authorization Response Verification

To verify the validity of the Authorization Response, the client MUST to the following:

  1. If the response was signed, the Client SHOULD verify the signature as in JWT as the first step.
  2. Check that OP that it connected was really the intended OP through TLS/SSL server certificate check if the endpoint is TLS/SSL endpoint.
  3. Check that current time is within the validity period.

If the client does not verify the signature, it MUST make a User Info API request.



 TOC 

8.3.  UserInfo Request Verification

If the request was signed, the Server MUST verify the signature as in JWS (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.) [JWS].



 TOC 

8.4.  UserInfo Response Verification

To verify the validity of the UserInfo Response, the client MUST to the following:

  1. If the response was signed, the Client SHOULD verify the signature as in JWT as the first step.
  2. Check that the OP that it connected was really the intended OP through TLS/SSL server certificate and check if the endpoint is TLS/SSL endpoint.
  3. Check if the current time is within the validity period.



 TOC 

9.  Other Items for Consideration



 TOC 

10.  IANA Considerations

This document makes no request of IANA.

Note to RFC Editor: this section may be removed on publication as an RFC.



 TOC 

11.  Security Considerations

This specification references the security considerations defined in OAuth 2.0 Security Considerations (Lodderstedt, T., Ed., McGloin, M., Hunt, P., and A. Nadalin, “OAuth 2.0 Security Considerations,” April 2011.) [OAuth2.0_securityconsiderations].

Followings are the list of attack vectors and remedies that were considered for this specification.

For details of the attack vector, see [SP800‑63] (National Institute of Standards and Technology, “NIST SP800-63rev.1: Electronic Authentication Guideline,” .).



 TOC 

11.1.  Assertion Manufacture/Modification

To mitigate this attack, there are two ways to mitigate it.

  1. The assertion may be digitally signed by the OP. The Relying Party SHOULD check the digital signature to verify that it was issued by a legitimate OP.
  2. The assertion may be sent over a protected channel such as TLS/SSL. In order to protect the integrity of assertions from malicious attack, the OP MUST be authenticated. In this specification, the assertion is always sent over TLS/SSL protected channel.


 TOC 

11.2.  Assertion Disclosure

The Assertion disclosure can be mitigated in the following two ways.

  1. Assertion is sent over TLS/SSL protected channel, where RP is authenticated by "client_id" and "client_secret".
  2. Signed Assertion is encrypted by the RP's public key.


 TOC 

11.3.  Assertion Repudiation

To mitigate this threat, the assertion may be digitally signed by the OP using a key that supports non-repudiation. The RP SHOULD check the digital signature to verify that it was issued by a legitimate OP.



 TOC 

11.4.  Assertion Redirect

To mitigate this threat, the assertion includes the identity of the RP for whom it was generated as "client_id". The RP verifies that incoming assertions include its identity as the recipient of the assertion.



 TOC 

11.5.  Assertion Reuse

The assertion includes a timestamp and a short lifetime of validity. The Relying Party checks the timestamp and lifetime values to ensure that the assertion is currently valid.



 TOC 

11.6.  Secondary Authenticator Manufacture

Due to the large entropy requirement of the Artifact ("code") and short life nature of its validity, the success probability of this attack is extremely low.



 TOC 

11.7.  Secondary Authenticator Capture

Secondary authenticator (="code") is transmitted only through HTTPS, thus it is protected between the OP and the User-Agent, and User-Agent and the RP.

Only the place it can be captured is the User-Agent where the TLS session is terminated, and is possible if the User-Agent is infested by malwares. However, it renders no usefulness as long as the profile in use either RP authentication or assertion encryption.



 TOC 

11.8.  Assertion Substitution

Responses to assertion requests is bound to the corresponding requests by message order in HTTP, as both assertions and requests are protected by TLS that can detect and disallow malicious reordering of packets.



 TOC 

11.9.  Authentication Request Disclosure

If the authentication request is POSTed directly through a protected channel, it is not possible to disclose the authentication request.

If the Request File is encrypted by the OP's public key, the authentication request will not be disclosed unless OP's private key gets compromised or the encryption algorithm becomes vulnerable.



 TOC 

11.10.  Timing Attack

Timing attack can be used to reduce the effective key length of the signature if the time required to return the response in case of a signature error and a correct signature differs. Care should be taken in the implementation to avoid this attack.



 TOC 

11.11.  Authentication Process Threats

In the category of Authentication Process Threats, following threats exists.

Authentication process per se as described in NIST SP800-63-rev1 is out of scope for this protocol, but care SHOULD be taken to achieve appropriate protection.



 TOC 

12. Normative References

[Bearer_Tokens] Jones, M., Hardt, D., and D. Recordon, “OAuth 2.0 Protocol: Bearer Tokens,” June 2011.
[ISO29115] McCallister, E., “ITU-T Recommendation X.eaa | ISO/IEC 2nd CD 29115 -- Information technology – Security techniques – Entity authentication assurance framework,” ISO/IEC 29115.
[JWE] Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Encryption,” March 2011.
[JWS] Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.
[JWT] Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” March 2011.
[OAuth2.0] Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” May 2011.
[OAuth2.0_securityconsiderations] Lodderstedt, T., Ed., McGloin, M., Hunt, P., and A. Nadalin, “OAuth 2.0 Security Considerations,” April 2011.
[OpenID.2.0] specs@openid.net, “OpenID Authentication 2.0,” 2007 (TXT, HTML).
[OpenID.AB] Sakimura, N., Ed., Bradley, J., de Medeiros, B., Ito, R., and M. Jones, “OpenID Connect Artifact Binding 1.0,” June 2011.
[OpenID.CC] Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC3339] Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” RFC 3339, July 2002 (TXT, HTML, XML).
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML).
[RFC4627] Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” RFC 4627, July 2006 (TXT).
[RFC5646] Phillips, A. and M. Davis, “Tags for Identifying Languages,” BCP 47, RFC 5646, September 2009 (TXT).
[SP800-63] National Institute of Standards and Technology, “NIST SP800-63rev.1: Electronic Authentication Guideline,” NIST SP800-63.
[SWD] Jones, M. and Y. Goland, “Simple Web Discovery,” January 2011.
[UserInfo.Endpoint] Sakimura, N., Bradley, J., de Medeiros, B., and M. Jones, “OpenID Connect UserInfo Endpoint 1.0,” June 2011.
[XRI_Syntax_2.0] Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” November 2005 (HTML, PDF).


 TOC 

Appendix A.  Acknowledgements



 TOC 

Appendix B.  Document History

-01
Added RFC5656/BCP47 locale information to claims requests.
-00
Split from core when all optional features were removed.



 TOC 

Authors' Addresses

  Nat Sakimura
  Nomura Research Institute, Ltd.
Email:  n-sakimura@nri.co.jp
  
  John Bradley
  Protiviti Government Services
Email:  jbradley@mac.com
  
  Michael B. Jones
  Microsoft Corporation
Email:  mbj@microsoft.com
  
  Breno de Medeiros
  Google
Email:  breno@google.com
  
  Chuck Mortimore
  Salesforce
Email:  cmortimore@salesforce.com
  
  Edmund Jay
  MGI1
Email:  ejay@mgi1.com