OpenID Connect Explained

Connect

explained

>>> connect2id.com :: 2014-01-21

http://connect2id.com/

>>> connect2id.com :: 2014-01-21OpenID Connect Explained

A Universal Solution?

● OpenID Connect provides Single Sign-On (SSO) for web and native clients alike

● Good for a range of domains:– consumer applications

– social applications

– enterprise applications

● Wide-spread adoption is supported by major backers such as Google and Microsoft



The OpenID Connect Framework

● Provides a standard SSO protocol on top of the OAuth 2.0 authorisation framework

● Simple clients, complexity absorbed by the server

● Allows implementation of arbitrary methods for authenticating users – LDAP, multi-factor, etc.

● Offers user provisioning

● Supports optional provider discovery, dynamic client registration and session management

● Extensible to suit many use cases

● SAML bridge available

OpenID Connect

OAuth 2.0JOSE

+JWT



OAuth 2.0 distilled

● Authorisation framework specified in RFC 6749, forms the basis of OpenID Connect.

● The authorisation server issues clients with access tokens (typically bearer) to allow them access to protected HTTP resources.

● The access token is issued in exchange for a valid “grant”:

– an explicit or implicit grant by sending the user to the authorisation server to be authenticated and authorise the client request;

– password credentials grant where the client passes the user's name and password to the server;

– client credentials grant where the client passes its own identifier and password;

– JWT or SAML assertion (signed proof of something).

● Each access token has an associated scope and expiration, and may optionally be refreshed.



OpenID Connect Artefacts

The OpenID Connect protocol produces two key artefacts:

– ID tokens (JWT)

– Access tokens (OAuth 2.0 bearer)

ID Token Access Token



ID Token

Resembles the concept of an identity card, but in a standard digital format that can be verified by clients

● Asserts the user's identity.

● Specifies the issuing authority (the IdP).

● May specify how (strength) and when the user was authenticated.

● Is generated for a particular audience (client).

● Has an issue and an expiration date.

● May contain additional subject details such as the user's name, email address and other profile information.

● Is digitally signed, so it can be verified by the intended recipients.

● May optionally be encrypted for confidentiality.



ID Token Encoding

{

"iss" : "https://c2id.com",

"sub" : "alice",

"aud" : "s6BhdRkqt3",

"nonce" : "n0S6_WzA2Mj",

"exp" : 1311281970,

"iat" : 1311280970,

"auth_time" : 1311280969,

"acr" : "urn:2fa",

"at_hash" : "MTI..."

}

● Encoded as a JSON Web Token (JWT).

● The claims about the subject are packed in a simple JSON object.

● Typically signed with the provider's private RSA key or a shared secret (HMAC) issued to the client during registration.

● Is URL-safe.



Cool ID Token Uses

● Can be used for basic session management:

– Check if the user is still logged in with the OpenID Connect provider.

– Initiate logout at the OpenID Connect provider.● May be passed to third authorised parties to assert the user's

identity.

● May be exchanged for an OAuth 2.0 access token at the token endpoint of an OAuth 2.0 authorisation server. The access token can then be used to make HTTP requests to one or more protected resources. This feature has great potential use in enterprise applications.



Access Token

Resembles the concept of a physical token or ticket. Gives the bearer access to a given resource or service. Can typically expire.

● OAuth 2.0 access tokens are employed in OpenID Connect to allow the client application to retrieve consented user information from the server, thus facilitating a form of user provisioning.

● The server may extend the access token scope to allow the client access to other protected resources and web APIs.

● The client treats the access token as simple opaque string to be passed with the HTTP request to the protected resource.

● The OAuth 2.0 spec gives server implementers complete flexibility in how the tokens are implemented and verified.



OpenID Connect Endpoints

● Core provider endpoints:

– Authorisation endpoint

– Token endpoint

– UserInfo endpoint

● Optional provider endpoints:

– WebFinger endpoint

– Provider configuration URI

– Provider JWK set URI

– Client registration endpoint

– Session management endpoint

HTTP Endpoints



Authorisation Endpoint

The authorisation endpoint is the only one where the end-user has to interact with the OpenID Connect provider. All remaining endpoints are meant for serving back-channel requests from the client application.

● The client application redirects the user's browser to the authorisation endpoint of the OpenID Connect server to authenticate.

● If the user has an active session with the OpenID Connect provider authentication may be skipped.

● If the client application has requested access to the user's details (name, contact info, etc) a consent screen is presented.

● The browser is redirected back to the client application with the encoded authentication result - authorisation code, ID token and/or access token.



Token Endpoint

● The purpose of this endpoint is to require the client application to authenticate itself and let it then exchange the received code from the authorisation endpoint for an ID token and access token.

● The client authentication is required to prevent token leaks.

● Being an OAuth 2.0 token endpoint it may also accept other grant types to issue tokens.

authorisationcode

ID token +access token



UserInfo Endpoint

● The UserInfo endpoint is an OAuth 2.0 protected resource.

● The client application must pass the access token it was issued in order to access it.

● The UserInfo returns consented profile information to the client application.

● The profile information is intended to facilitate user provisioning.

● It is JSON encoded and may optionally be packaged as a JWT that is signed or encrypted.

{ “sub” : “alice”, “name” : “Alice Adams”, “email” : “[email protected]”, “website” : “http://alice.me”, “picture” : “http://alice.me/pic.jpg”, “birthdate” : “1980-05-31”}

UserInfo



Optional Endpoints

● WebFinger: enables dynamic discovery of the OpenID Connect provider for a user based on their email address.

● Provider configuration URI: well-known URI returning endpoint and other provider information such as optional capabilities; the client applications can use it to configure their OpenID Connect requests to the provider.

● Provider JWK set URI: JSON document containing the provider's public (typically RSA) keys in JSON Web Key (JWK) format; these keys are used to secure the issued ID tokens and other artefacts.

● Client registration: enables client applications to register dynamically, then update their details or unregister; registration may be open (public).

● Session management: enables client applications to check if a logged in user has still an active session with the OpenID Connect provider; also to signal logout.



Specifications

● OpenID Connect: http://openid.net/connect

● OAuth 2.0 (RFC 6749): http://tools.ietf.org/html/rfc6749

● OAuth 2.0 Bearer token (RFC 6750): http://tools.ietf.org/html/rfc6750

● JSON Web Signature: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-20

● JSON Web Encryption: http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-20

● JSON Web Key: http://tools.ietf.org/html/draft-ietf-jose-json-web-key-20

● JSON Web Token: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-15


http://openid.net/connect

http://tools.ietf.org/html/rfc6749

http://tools.ietf.org/html/rfc6750

http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-20

http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-20

http://tools.ietf.org/html/draft-ietf-jose-json-web-key-20

http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-15

Technology

OpenID Connect Explained