TOC 
Network Working GroupN. Sakimura
Internet-DraftNRI
Intended status: ExperimentalJ. Bradley
Expires: December 31, 2011Protiviti Government Services
 M. Jones
 Microsoft
 B. de Medeiros
 Google
 C. Mortimore
 Salesforce
 E. Jay
 MGI1
 June 29, 2011


OpenID Connect Session Management 1.0 - draft 00
openid-connect-session-1_0.xml

Abstract

This document describes how to manage sessions 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 December 31, 2011.

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.  Session Management
    3.1.  Creating Sessions
        3.1.1.  ID Token
        3.1.2.  Authorization Request
        3.1.3.  Token Endpoint
        3.1.4.  Implicit (User-Agent) Flow
        3.1.5.  Authorization Code (Web Server) Flow
        3.1.6.  4th Party Native Applications
    3.2.  Session Management Endpoints
        3.2.1.  Refresh Session
        3.2.2.  Check Session
        3.2.3.  End Session
    3.3.  Session Synchronization
4.  Other Items for Consideration
5.  IANA Considerations
6.  Security Considerations
7.  Normative References
Appendix A.  Acknowledgements
Appendix B.  Document History
§  Authors' Addresses



 TOC 

1.  Introduction

Sessions are used to keep track of information and interactions for users across multiple pages. This creates a sense of continuity, customization, and a more pleasant experience for the users. Visitors to an OpenID relying party site accessing protected resources will be asked for authentication and authorization. Upon user authorization, the user will be granted access to the requested resources. The site may perform other background tasks for the user using the same authenticated session. This allows the user to have a simplified experience without being asked for authorization each time and may even allow the user to go off-line while the tasks are being performed. This specification describes how OpenID Connect sessions can be created, used, and terminated.


 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:

Client
An application obtaining authorization and making protected resource requests.
End-user
A human resource owner.
Client Identifier
A unique identifier that the client uses to identify itself to the OP.
Identifier
An Identifier is either an "http" or "https" URI, (commonly referred to as a "URL" within this document), or an account URI. This document defines various kinds of Identifiers, designed for use in different contexts.
ID Token
An opaque token that contains claims about an authenticated user.
ID Token
A JWS signed claim that attest to the identity of the user, intended audience, and the issuer of the claim. The signed claim uses compact serialization.

 TOC 

3.  Session Management

The OpenID Connect Core supports life-cycle session management and synchronization for third parties that support authentication with the authorization server. In addition, session management for fourth parties such as desktop, native or mobile applications that utilizes authorization server credentials at fourth party web sites are also supported.


 TOC 

3.1.  Creating Sessions

To create a session, the client sends an authorization request to the authorization server with id_token as one of the response_type values.

If the response_type includes the value code, then an ID token (ID Token) is returned in the response of the Token Endpoint when the Access Token is retrieved.

If the response_type includes the value token, then an ID token is returned as a fragment parameter in the redirect_uri specified in the request.

In either case, an ID Token will also be returned along with the access token when submitting a refresh token to the token access endpoint if the initial authorization request included id_token in the response_type parameter.

The ID Token serves as a key to an authenticated user session and contains claims for the user.


 TOC 

3.1.1.  ID Token

This specification defines ID Token as a JWS signed claim that minimally attests the following claims:

issuer
REQUIRED. The unique identifier of the issuer of the claims
client_id
REQUIRED. The unique identifier of the client.
user_id
REQUIRED. A locally unique and never reassigned identifier for the user, which is intended to be consumed by the Client. e.g. "24400320" or "AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4". It MUST NOT exceed 255 ASCII characters in length.
audience
REQUIRED. The JWT (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” March 2011.) [JWT] aud (audience) claim.
exp
REQUIRED. The JWT (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” March 2011.) [JWT] exp (expiration time) claim.
pape
OPTIONAL. (TBD) If we want this token to be short, we probably want to define a shorter equivalent of PAPE.
nonce
OPTIONAL. If the authorization request includes a nonce request value, then this value is REQUIRED and its value is set to the same value as the request value.

The ID Token MAY contain other claims. The ID Token can be used to access session information from an authenticated session or to pass a session to other applications.

The ID Token MAY be redefined by other OpenID session related specifications.


 TOC 

3.1.2.  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. In this specification, the values to the parameters are defined as follows.

response_type
A space delimited, case sensitive list of string values (Pending OAuth 2.0 changes). This specification extends the OpenID Core response_type values to include id_token . The value MUST include id_token for requesting an ID Token from a session.

In addition, this specification defines the following extension parameters.

nonce
OPTIONAL. A random, unique string. The nonce value is returned in the ID token.
id_token_audience
OPTIONAL. The identifier of the target audience for an ID token.

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

GET /authorize?scope=openid&response_type=token%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
Host: server.example.com

 TOC 

3.1.3.  Token Endpoint

The Token Endpoint MUST return an ID Token if id_token is included in the response_type parameter of the authorization request.


 TOC 

3.1.3.1.  Access Token Response

After receiving and verifying a valid and authorized Access Token Request from the client, the Authorization Server returns a Positive Assertion that includes an Access Token. The parameters in the successful response are defined in Section 4.2.2 of OAuth 2.0 (Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2.0] .

In addition, this specification defines the following additional return parameters:

id_token
REQUIRED if it was requested in the authorization request. It may be a JWS (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.) [JWS] of the ID token (ID Token) described below.

Following is a non-normative example. 

{
    "access_token": "SlAV32hkKG",
    "token_type": "JWT",
    "refresh_token": "8xLOxBtZp8",
    "expires_in": 3600,
    "id_token":"jwtheader.jwtpayload.jwtcrypto"
}

As in the OAuth 2.0 (Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2.0], Clients SHOULD ignore unrecognized response parameters.


 TOC 

3.1.4.  Implicit (User-Agent) Flow

User-agents can use the OAuth implicit grant flow by including token and id_token in the response_type of the authorization request to get an ID Token.

  1. The user-agent makes an authorization request to the authorization endpoint.
  2. The authorization server authenticates the user
  3. The authorization server returns an access and ID token.
  4. The user-agent and client servlet can then use the session management endpoints by presenting the ID token to the endpoints. 

                                 +----------------------------------+
+----------+                     |                                  |
|          |                     |      +----------------------+    |
|          |                     |      |    Authorization     |    |
|          |                     |      |         server       |    |
|user-agent|                     |      +----------------------+    |
|          |                     |      |   +---------------+  |    |
|          |>----(1)-------------|------|-->| Authorization |  |    |
|          |<----(3)-------------|------|--<| Endpoint  (2) |  |    |
+----------+                     |      |   +---------------+  |    |
    ^                 +----------|------|--<| Check_Session |  |    |
    |                 | +--------|------|-->| EndPoint      |  |    |
    |                 | |        |      |   +---------------+  |    |
    v                 | |        |      +----------------------+    |
+----------+       (4)| |        |                                  |
|          |          | |        |                                  |
|client    |<---------+ |        |      +----------------------+    |
|servlet   |>-----------+        |      |     Profile API/     |    |
|          |                     |      |     UserInfo Endpoint|    |
|          |                     |      |                      |    |
|          |>--------------------|----->|                      |    |
|          |<--------------------|-----<|                      |    |
|          |                     |      |                      |    |
|          |                     |      |                      |    |
+----------+                     |      +----------------------+    |
                                 |                                  |
                                 |                                  |
                                 +----------------------------------+


                             +-----------------------------+
                             |                             |
                             |      Authorization          |
                             |         Server              |
+-------------+              |                             |
|             |              |     +--------------------+  |
| User-Agent  |              |     |  Refresh Session   |  |
|             |    (4)       |     |    Endpoint        |  |
|             |>-------------|---->|                    |  |
|             |<-------------|----<|                    |  |
|             |              |     |                    |  |
|             |              |     +--------------------+  |
|             |    (4)       |     |  End Session       |  |
|             |>-------------|---->|    Endpoint        |  |
|             |<-------------|----<|                    |  |
|             |              |     |                    |  |
|             |              |     +--------------------+  |
+-------------+              +-----------------------------+


 TOC 

3.1.4.1.  Implicit Flow Request

The authorization request parameter values are constrained as follows.

response_type
A space delimited, case sensitive list of string values (Pending OAuth 2.0 changes). The value MUST include token and id_token and to request an access and ID Token from the session.

Following is a non-normative example of a request using query parameters serialization. 

GET /authorize?scope=openid&response_type=token%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
Host: server.example.com


 TOC 

3.1.4.2.  Implicit Flow Response

When the response_type in the request includes token, the Authorization Response MUST return the parameters defined in section 4.2.2 of OAuth 2.0 (Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2.0].

In addition, when response_type includes id_token, an ID Token MUST be returned in the response.

Following is a non-normative example of a response: 

HTTP/1.1 302 Found
Location: https://client.example.com/cb?token=i1WsRn1uB1&id_token=jwt_header.jwt_payload.jwt_crypto

 TOC 

3.1.5.  Authorization Code (Web Server) Flow

Web server clients can use the OAuth authorization code flow by including code and id_token in the response_type parameter of the authorization request to obtain an ID token. The ID Token is returned along with the access token after the client submits the authorization code to the access token endpoint.

  1. The user-agent makes an authorization request to the authorization endpoint.
  2. The authorization server authenticates the user
  3. The authorization server returns an authorization code.
  4. The client sends authorization code to the token access endpoint.
  5. The authorization server verifies the authorization token and returns an access and ID token
  6. The user-agent and client servlet can then use the session management endpoints by presenting the ID token to the endpoints. 

                                 +----------------------------------+
+----------+                     |                                  |
|          |                     |      +----------------------+    |
|          |                     |      |    Authorization     |    |
|          |                     |      |         server       |    |
|user-agent|                     |      +----------------------+    |
|          |                     |      |   +---------------+  |    |
|          |>-----(1)------------|------|-->| Authorization |  |    |
|          |<-----(3)------------|------|--<| Endpoint (2)  |  |    |
+----------+                     |      |   +---------------+  |    |
    ^                 +----------|------|--<| Access Token  |  |    |
    |                 | +--------|------|-->| EndPoint      |  |    |
    |                 | |        |      |   +---------------+  |    |
    v                 | |        |      |   | Session       |  |    |
+----------+          | |        |      |   | Management    |  |    |
|          |          | |        |      |   | Endpoints     |  +    |
|client    |<-----(4)-+ |        |      |   +---------------+  |    |
|servlet   |>-----(5)---+        |      +----------------------+    |
|          |                     |                                  |
|          |                     |      +----------------------+    |
|          |                     |      |     Profile API/     |    |
|          |                     |      |     UserInfo Endpoint|    |
|          |<--------------------|-----<|                      |    |
|          |>--------------------|----->|                      |    |
+----------+                     |      +----------------------+    |
                                 |                                  |
                                 |                                  |
                                 +----------------------------------+


 TOC 

3.1.5.1.  Authorization Code Flow Request

The authorization request parameter values are constrained as follows.

response_type
A space delimited, case sensitive list of string values (Pending OAuth 2.0 changes). The value MUST include code and id_token and to request an access and ID Token from the session.

Following is a non-normative example of a request using query parameters serialization. 

GET /authorize?scope=openid&response_type=code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
Host: server.example.com


 TOC 

3.1.5.2.  Authorization Code Flow Response

When the response_type in the request includes code, the Authorization Response MUST return the parameters defined in section 4.1.2 of OAuth 2.0 (Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2.0].

In addition, when response_type includes id_token, the ID token is retrieved from the token access endpoint.

Following is a non-normative example of a response: 

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=i1WsRn1uB1

 TOC 

3.1.5.3.  Token Access Request

The client uses the authorization code to make a request to the token access endpoint to retrieve an access and ID token.

The request format is defined in section 4.1.3 of the OAuth 2.0 (Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2.0] specification.

Following is a non-normative example of a token access endpoint request: 

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&client_id=s6BhdRkqt3&
code=i1WsRn1uB1&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

 TOC 

3.1.5.4.  Token Access Response

The access and ID token is returned in the response.

The request format is defined in section 4.1.4 of the OAuth 2.0 (Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2.0] specification.

Following is a non-normative example of a token access endpoint response: 

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
  "access_token":"SlAV32hkKG",
  "token_type":"JWT",
  "expires_in":3600,
  "refresh_token":"8xLOxBtZp8",
  "id_token":"jwt_header.jwt_payload.jwt_crypto"
}

 TOC 

3.1.6.  4th Party Native Applications

Fourth party native applications involve four parties: 1) the user, 2) the native (desktop) application, 3) the authorization server, and 4) the client servlet web application. The native application uses protected resources from a client servlet but it integrates with authentication services from the authorization server directly. The native application directs the user to perform authentication at the authorization server to obtain access and ID tokens. The tokens can then be used to access protected resources at the web servlet client. The process of obtaining an ID Token for the native application is very similar to that of using the code authorization (web server) flow method. However, the target audience of the ID Token is not the native application, but that of the client servlet. The client needs to indicate the target audience for the ID Token by setting the id_token_audience parameter in the authorization request to that of the identifier of the client servlet. 

                                     +-----------------------------+
+----------------+                   |                             |
|                |                   |   Authorization             |
|   Native App   |                   |      Server                 |
|                |                   |                             |
|                |                   |      +--------------------+ |
|                |>------------------|----->| Authorization      | |
|                |<------------------|-----<|   Endpoint         | |
|                |                   |      |                    | |
|                |                   |      |                    | |
|                |                   |      +--------------------+ |
|                |                   |      | Access Token       | |
|                |>------------------|----->|   Endpoint         | |
|                |<------------------|-----<|                    | |
|                |                   |      |                    | |
|                |                   |      +--------------------+ |
|                |>------------------|----->| Session Mgmt       | |
|                |<------------------|-----<|   Endpoints        | |
|                |                   |      |                    | |
+----------------+                   |      |                    | |
        ^                            |      |                    | |
        |                            |      +--------------------+ |
        v                            |                             |
+----------------+                   |                             |
| Client         |                   +-----------------------------+
| Servlet        |
|                |
+----------------+

When accessing protected resources at the client servlet, the native application sends the ID Token as an Auth HTTP header in the request. The client servlet can check the validity of the ID Token by verifying the cryptographic information or by sending the token to the check session token endpoint. 

GET /resource1
Auth: idtoken_jwt_header.idtoken_jwt_payload.idtoken_jwtcrypto
Host: servlet.example.com


 TOC 

3.1.6.1.  Browser Load

Some native applications may wish to start an authenticated browser session for the same user. The native application starts a browser with the location of the client servlet and passing an ID Token as a query parameter. The client servlet immediately initiates a request to the refresh session endpoint with the ID Token. The user may need to reauthenticate at the authorization server. The client servlet then gets an ID Token that is session synchronized with the authorization server. 

                                        +--------------------------+
+------------+      +-----------+       |                          |
|            |      |           |       |   Authorization Server   |
| Native App |>---->|User-Agent |       |                          |
|            |      |           |       |    +------------------+  |
|            |      |           |>------|--->| Session Refresh  |  |
|            |      |           |<------|---<|    Endpoint      |  |
+------------+      +-----------+       |    |                  |  |
      ^                   ^             |    +------------------+  |
      |                   |             |                          |
      v                   v             |                          |
+--------------------------------+      |                          |
|                                |      |                          |
|       Client Servlet           |      |                          |
|                                |      |                          |
+--------------------------------+      +--------------------------+



GET
/refesh_token?state=bar&redirect_uri=https://foo.com/oauth2callback&id_token=$id_token // never uses immediate mode here, to allow login
Host: www.example.com

Response:

HTTP/1.1 302 Found
Location: https://foo.com/oauth2callback?state=bar&session=$new_id_token


 TOC 

3.2.  Session Management Endpoints

To manage a session, the client sends a request to the session management endpoints at the authorization server. The session management endpoints at the authorization server are:

Refresh Session
Refreshes an expired ID Token
Check Session
Get a plain text JSON structure from a ID Token
End Session
Ends a session


 TOC 

3.2.1.  Refresh Session

To refresh an ID Token that has expired, the client sends a request to the Refresh Session endpoint with an ID Token. A new ID Token is returned in JWS format.

Request Parameters:

id_token
REQUIRED. A previously issued ID Token from an authorization request. The ID Token MAY be expired.
state
REQUIRED. An opaque value used by the Client to maintain state between the request and callback. If provided, the Authorization Server MUST include this value when redirecting the user-agent back to the Client. Clients are strongly advised to use this variable to relate the request and response.
redirect_uri
REQUIRED. An absolute URI to which the authorization server will redirect the user-agent to with the new ID Token.

Response:

The response is a new ID Token. In a typical HTTP binding, an HTTP 302 redirect to the specified redirect_uri in the request with a new ID Token.

id_token
A new ID Token

The following is a non-normative session refresh request: 

Request:

GET /op/refresh_session?id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6
ImNsaWVudC5leGFtcGxlLmNvbSJ9.eyJpc3N1ZXIiOiJodHRwOlwvXC9zZXJ2ZXIuZXhhbXBs
ZS5jb20iLCJjbGllbnRfaWQiOiJjbGllbnQuZXhhbXBsZS5jb20iLCJhdWRpZW5jZSI6ImNsa
WVudC5leGFtcGxlLmNvbSIsImlkIjoidXNlcl8yMzQyMzQiLCJleHAiOjEzMDM4NTI4ODB9.a
JwagC6501Da-zK-X8Az9B-Y625aSEfxVuBpFEDjOxQ
&state=bar&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fidtoken_cb
Host: server.example.com

Response:

HTTP/1.1 302 OK
Location: http://client.example.com/idtoken_cb#id_token=eyJ0eXAiOiJKV1QiLCJh
bGciOiJIUzI1NiIsImtpZCI6ImNsaWVudC5leGFtcGxlLmNvbSJ9.eyJpc3N1ZXIiOiJodHRwO
lwvXC9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJjbGllbnRfaWQiOiJjbGllbnQuZXhhbXBsZS5jb20
iLCJhdWRpZW5jZSI6ImNsaWVudC5leGFtcGxlLmNvbSIsImlkIjoidXNlcl8yMzQyMzQiLCJle
HAiOjEzMDM4NTI4ODB9.aJwagC6501Da-zK-X8Az9B-Y625aSEfxVuBpFEDjOxQ&state=bar&
expires_in=3600


 TOC 

3.2.2.  Check Session

For clients that are not capable of dealing with JWS signed ID Tokens, they can send the ID Token to the Check Session endpoint. It will validate the ID Token and return a plain text JSON structure of the ID Token.

Request Parameters:

id_token
REQUIRED. A previously issued ID Token

Response:

The response body is a plain text JSON structure of the claims in the ID token.

If the ID token is a JWS (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.) [JWS], then it is the base64url decoded payload of the signed ID Token. In a typical HTTP binding, the response is a HTTP 200 response code with the content-type header set to "application/json".

The following is a non-normative example of a check session request: 

Request:
POST /op/check_session?id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6
ImNsaWVudC5leGFtcGxlLmNvbSJ9.eyJpc3N1ZXIiOiJodHRwOlwvXC9zZXJ2ZXIuZXhhbXBs
ZS5jb20iLCJjbGllbnRfaWQiOiJjbGllbnQuZXhhbXBsZS5jb20iLCJhdWRpZW5jZSI6ImNsa
WVudC5leGFtcGxlLmNvbSIsImlkIjoidXNlcl8yMzQyMzQiLCJleHAiOjEzMDM4NTI4ODB9.a
JwagC6501Da-zK-X8Az9B-Y625aSEfxVuBpFEDjOxQ

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

{
  "issuer":"http://server.example.com",
  "client_id","http://client.example.com",
  "audience", "http://client.example.com",
  "user_id":"user_328723",
  "exp":1303852880
}


 TOC 

3.2.3.  End Session

To end the session, the client sends an ID Token to the End Session endpoint. Upon receiving the request, the authorization server performs the logout flow for the user and then redirects the user-agent to the specified redirect_uri.

Request Parameters:

id_token
REQUIRED. A previously issued ID Token
state
REQUIRED. An opaque value used by the Client to maintain state between the request and callback. If provided, the Authorization Server MUST include this value when redirecting the user-agent back to the Client. Clients are strongly advised to use this variable to relate the request and response.
redirect_uri
REQUIRED. An absolute URI to which the authorization server will redirect the user-agent.

Response:

The response is dependent on the particular binding. In HTTP binding, the response is a HTTP 302 redirect response to the redirect_uri specified in the request.

The following is a non-normative session refresh request: 

Request:

GET /op/end_session?id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6
ImNsaWVudC5leGFtcGxlLmNvbSJ9.eyJpc3N1ZXIiOiJodHRwOlwvXC9zZXJ2ZXIuZXhhbX
BsZS5jb20iLCJjbGllbnRfaWQiOiJjbGllbnQuZXhhbXBsZS5jb20iLCJhdWRpZW5jZSI6I
mNsaWVudC5leGFtcGxlLmNvbSIsImlkIjoidXNlcl8yMzQyMzQiLCJleHAiOjEzMDM4NTI4
ODB9.aJwagC6501Da-zK-X8Az9B-Y625aSEfxVuBpFEDjOxQ
&state=bar
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fendtoken_cb
Host: server.example.com

...
   Authorization server performs logout flow
...

Response:

HTTP/1.1 302 OK
Location: http://client.example.com/endtoken_cb?state=bar


 TOC 

3.3.  Session Synchronization

An ID Token is usually bound to a user's sign in session at the authorization server, but in some cases, such as offline access by a web server or native application, it may not be. ID Tokens obtained in the following scenarios are bound to a user's signed-in state at the authorization server:

ID Tokens obtained in the above manner are session synchronized.

If an ID Token is obtained by submitting a refresh token at the access token endpoint, then the resulting ID Token is not bound to a user's sign in state at the authorization server. The client may be in offline mode or the user has logged out from the authorization server. If a session bound ID Token is desired, the client should obtain a new ID Token by sending a request to the refresh session endpoint.


 TOC 

4.  Other Items for Consideration


 TOC 

5.  IANA Considerations

This document makes no request of IANA.

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


 TOC 

6.  Security Considerations


 TOC 

7. Normative References

[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).
[SWD] Jones, M. and Y. Goland, “Simple Web Discovery,” January 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

-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