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.
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.
- The Resource Owner (RO)
The entity that is in control of the data exposed by the API, typically the end user.
- Client
The mobile app, web app, site etc that wants access to the data on behalf of the RO.
- Authorization Server (AS)
The security token service, the Oauth server that issues the token.
- 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:
- Access Tokens: These are the tokens that are presented to the API.
- 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.
- The OpenID Providers (OPs)
The Oauth 2.0 authentication servers which implement the OpenID Connect are considered the OPs.
- 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.
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:
-
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.
-
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.
-
Hybrid Flow Some tokens returned from the authorization endpoint, and some of them returned from the token endpoint.
- The RP sends the request to the OpenID Provider to authenticate the end user.
- The OpenID Provider authenticates the user
- The OpenID Provider sends the ID token and access token to the RP
- The RP sends a request to the user info endpoint with the access token recieved from the OpenID Provider
- The user info endpoint returns the claims.