| TOC |
|
OpenID Connect is an identity framework that provides authentication, authorization, and attribute transmission capability. It allows third party attested claims from distributed sources. The specification suite consists of Core, Protocol Bindings, Dynamic Registration, Discovery, and Extensions. This specification is the "Dynamic Registration" part of the suite that defines how clients register with OpenID Providers.
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].
1.
Introduction
2.
Terminology
3.
Discovery
4.
Client Registration Endpoint
4.1.
Request
4.2.
Response
5.
Other Items for Consideration
6.
IANA Considerations
7.
Security Considerations
8.
Normative References
Appendix A.
Acknowledgements
Appendix B.
Document History
§
Authors' Addresses
| TOC |
In order for an OpenID client to utilize OpenID services for a user, the client needs to register with the OpenID Provider to acquire a client ID and shared secret. This document describes how a new client can register with the provider, and how a client already in possession of a client_id can retrieve updated registration information.
The Client Registration endpoint may be co-resident with the token endpoint as an optimization in some deployments.
| TOC |
- Client
- An application obtaining authorization and making protected resource requests.
- End-user
- A human resource owner.
- Principal
- A human resource owner that is the target of a request in Simple Web Discovery.
- OpenID Provider (OP)
- Authorization Servers that are able to support OpenID Connect Messages.
- Relying Party (RP)
- Client and Resource Servers.
- End-User Authorization Endpoint
- The Authorization Server's endpoint capable of authenticating the End-User and obtaining authorization.
- Client Identifier
- A unique identifier that the client uses to identify itself to the OP.
- Token Endpoint
- The Authorization Server's HTTP endpoint capable of issuing tokens.
- OP Endpoints
- End-User Authentication, Authorization, and Token Endpoint.
- RP Endpoints
- The endpoint to which the OP responses are returned through redirect.
- UserInfo Endpoint
- A protected resource that when presented with a token by the client returns authorized information about the current user.
- 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.
| TOC |
OpenID Connect uses the registration_endpoint from the Provider Configuration Response Sec 4.2 (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” July 2011.) [OpenID.CD].
| TOC |
The Client Registration Endpoint returns registration information for the client to configure itself for the OpenID Provider.
| TOC |
Clients MAY send POST requests with the following parameters form encoded in the POST body to the Client Registration Endpoint.
- type
- REQUIRED. Values "client_associate", "client_update"
- client_id
- OPTIONAL. Used with "client_update"
- client_secret
- OPTIONAL. Used with "client_update"
- contact
- OPTIONAL. Comma separated list e-mail addresses for people allowed to administer the application.
- application_type
- OPTIONAL. "native" or "web"
- application_name
- OPTIONAL. Name of the application to be presented to the user.
- logo_url
- OPTIONAL. URL that a logo for the application can be retrieved from.
- redirect_url
- OPTIONAL. Comma separated list of redirect URL
- js_origin_url
- OPTIONAL. Comma separated list of Java Script Origins (used for Post Message flow)
- jwk_url
- OPTIONAL. URL for the RP's JSON Web Key (Jones, M., “JSON Web Key (JWK),” April 2011.) [JWK]
POST /oauth/token type=client_associate&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2callback HTTP/1.1 Host: server.example.com
| TOC |
The response is returned as a JSON object with all the parameters as top level elements.
- client_id
- REQUIRED. The unique client identifier
- client_secret
- REQUIRED. The client secret. This should change with each response.
- expires_in
- REQUIRED. The number of seconds that this id and secret are good for or "0" if it does not expire.
The following is an example response.
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"client_id":"SlAV32hkKG",
"client_secret":"cf136dc3c1fd9153029bb9c6cc9ecead918bad9887fce6c93f31185e5885805d",
"expires_in":3600
}
| TOC |
| TOC |
This document makes no request of IANA.
| TOC |
Since requests to the client registration endpoint result in the transmission of clear-text credentials (in the HTTP request and response), the server MUST require the use of a transport-layer security mechanism when sending requests to the token endpoint. The server MUST support TLS 1.2 as defined in [RFC5246], and MAY support additional transport-layer mechanisms meeting its security requirements.
| TOC |
| [JWK] | Jones, M., “JSON Web Key (JWK),” April 2011. |
| [OpenID.CC] | Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011. |
| [OpenID.CD] | Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” July 2011. |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (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). |
| TOC |
| TOC |
[[ to be removed once the specification is approved ]]
-02
-01
| TOC |
| Nat Sakimura | |
| Nomura Research Institute, Ltd. | |
| Email: | n-sakimura@nri.co.jp |
| John Bradley (editor) | |
| Protiviti Government Services | |
| Email: | jbradley@mac.com |
| Michael B. Jones | |
| Microsoft Corporation | |
| Email: | mbj@microsoft.com |