Skip to content

Instantly share code, notes, and snippets.

@joshuatobin

joshuatobin/OpenID-Connect.md

Last active December 10, 2015 14:55
Show Gist options
  • Save joshuatobin/14688a5a2941c6e61db9 to your computer and use it in GitHub Desktop.
Save joshuatobin/14688a5a2941c6e61db9 to your computer and use it in GitHub Desktop.
Download ZIP
OpenID Connect Notes
Raw
OpenID-Connect.md

OpenID-Connect (OPIC)

Authentication Protocol built on top of OAuth 2.0. AKA "Identity framework build on TOP of Oauth 2.0" It extends the authorization process of Oauth2.0 to implement its authentication. This facilitates the client to verify the end user identity against authentication performed by an authorization server. It also provides methods to transfer the end user information.

OAuth

Some points about Oauth quick:

  • It provides Delegated access
  • Reduction of password sharing between users and 3rd parties
  • Revocation of access.

There are 4 primary actors in Oauth.

  1. The Resource Owner (RO)

The entity that is in control of the data exposed by the API, typically the end user.

  1. Client

The mobile app, web app, site etc that wants access to the data on behalf of the RO.

  1. Authorization Server (AS)

The security token service, the Oauth server that issues the token.

  1. Resource Server (RS)

The services that exposes the data, IE the API

OAuth defines scopes. These are like permissions or delegated rights that the RO wishes the client to be able to do. The client may request certain rights, but the user may only grant someo fo them.

There are two kinds of tokens:

  1. Access Tokens: These are the tokens that are presented to the API.
  2. Refresh Tokesn: These are used by the client to get a new access token from the AS

Think of the tokens like a web session. If the session is valid, you can continue. Once the session expires, you can get a new one by logging in.

Two main parties involved in the authentication process of OpenID Connect.

  1. The OpenID Providers (OPs)

The Oauth 2.0 authentication servers which implement the OpenID Connect are considered the OPs.

  1. Relying Parties (RPs).

The clients who are using OpenID-Connect are known as the RPs.

To authenticate with OpenID-connect the RP (client) should have information about the OPs, the provider. Information such as the endpoint, the token endpoint, etc.

OPIC uses ID tokens in the form of Json Web Tokens.

How the authentication is handled

OPIC performs authentication to make sure the user is logged in at the provider endpoint. It then returns the result to the RP using and ID token (JSON web token), which then contains the login status of the end user, info on the issuer, expiration, etc.

There are 3 flows available:

  1. Authorization code flow No access token provided to the client. It gives an authorization code which can be exchanged for an ID token and access token. The auth server then only authorizes after this exchange.

  2. Implicit Flow The ID token and access token are directly returned to the client. In this flow the server does not perform client authentication. This flow is for web browser clients, scripts etc. This flow does not use the token endpoint. Instead it returns all token from the authorization endpoint.

  3. Hybrid Flow Some tokens returned from the authorization endpoint, and some of them returned from the token endpoint.

How the protocol works

  1. The RP sends the request to the OpenID Provider to authenticate the end user.
  2. The OpenID Provider authenticates the user
  3. The OpenID Provider sends the ID token and access token to the RP
  4. The RP sends a request to the user info endpoint with the access token recieved from the OpenID Provider
  5. The user info endpoint returns the claims.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment