OpenID Connect (OIDC) Example
What is OpenID Connect?
OpenID Connect (OIDC) is an identity layer that works on top of the OAuth.
If you aren't familiar with OAuth, check out this 5 minute OAuth example first.
OpenID Connect Example
Let's say you want to login to an application using Facebook.
The OpenID provider (OP) is Facebook.
The Relying party (RL) is the application you want to login to.
1) The RL redirects the user to the OP.
2) The OP validates the identity of the user via username/password, biometrics, or some other authentication method.
3) The OP redirects the user back to the RL with an authorization code.
4) The RL sends a token request to the OP with the authorization code.
5) The OP sends back an ID token, access token, and optionally a refresh token.
6) The RL uses the ID token to get profile information about the user.
7) The RL uses the access token to make authorized requests to the OP protected API.
The OpenID Connect Flow
OIDC builds on existing flows found in OAuth.
Authorization Code: The example above describes the authorization code flow. This flow obtains an authorization code prior to hitting a token endpoint for the ID and auth tokens. This flow is preferred when calling clients have a backend for securely storing access tokens.
Implicit: This flow skips the authorization code step and simply returns the ID token back to the client. This flow is preferable for public clients like single page web apps (SPA) that don't need to securely store access tokens. If a SPA only needs authentication, the implicit flow is perfect because it can return an ID token with user information safely via front end channels (like a web browser).
Hybrid: This flow is a combination of the authorization code and implicit flows. It relies on a front-channel response to return the ID token and authorization code to the front end. Once the ID token is validated, a supporting backend uses the returned authorization code to obtain additional access token for securely accessing the API.
ID Tokens
ID tokens are a fundamental part of OIDC that separates it from basic OAuth flows. The ID token contains user claims or attributes about the user that can be used to understand WHO the user is.
This is what allows OIDC to provide authentication on top of the authorization provided by OAuth.
The following is an example of an ID Token...
{
"iss": "http://stackchief.com",
"sub": "auth0|123456",
"aud": "my_client_id",
"exp": 1311281970,
"iat": 1311280970,
"name": "Sam Erickson",
"given_name": "Sam",
"family_name": "Erickson",
"birthdate": "0000-10-31",
"email": "stackchief@gmail.com",
"picture": "http://example.com/sam/me.jpg"
}
While the attributes or claims in these tokens may vary depending on the OIDC implementation, the OIDC specification requires the following four attributes:
iss - The issuer of the token aka the OpenID provider
sub - A unique identifier for the end user
exp - The expiration date of the token
iat - When the token was issued
The UserInfo Endpoint
OpenID providers expose UserInfo endpoints. These endpoints can be optionally used to get additional information/claims about a user. Using a valid access token, the client calls the endpoint and gets back user profile information in the response.
This is useful when user claims are too large to fit into a standard ID token returned via a URL fragment etc.
OpenID Connect vs OAuth2
OIDC adds an identity layer to OAuth2. OIDC is not a replacement for OAuth. Rather, OIDC compliments OAuth by implementing the open standard with authentication on top of the authorization provided by regular OAuth.
OIDC uses OAuth(2). OIDC does not replace OAuth.
While OAuth(2) authorizes a client application to securely access user data on another site, it doesn't address authentication by itself. OIDC provides this authentication by allowing clients to validate the person accessing the protected resources is who they say they are.
Conclusion
OIDC provides authentication on top of the basic OAuth flow.
OpenID providers similar flow to basic OAuth with the addition of identity tokens and user info endpoints. These elements allow clients to get information about users while also allowing them to get access tokens/refresh tokens needed to gain authorized access protected resources.
