Updated: Sep 27, 2022
This article will try to explain OpenID connect, also called OIDC. OIDC is one of the most popular authentication protocols. It is simple and flexible and can support various scenarios.
OIDC is built on top of OAuth 2.0; simply put, OIDC provides a thin layer on top of OAuth 2.0 to do its job. So, to understand OIDC, we need to understand OAuth 2.0 first. Before we provide a formal definition of OAuth 2.0, it is essential to understand the context of the OAuth 2.0 protocol.
A Resource is User data hosted by a web application like documents, images, videos, or other data.
A resource Owner is an entity capable of granting access to a protected resource. For simplicity, we can assume an end-user could be a resource owner.
A resource Server is an entity hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
A client is an application that requests a protected resource on behalf of the Resource Owner.
Authorization Server issues tokens to the client after successfully authenticating the resource owner and obtaining authorization.
Let's define Auth2.0
The OAuth 2.0 is the industry protocol for authorization. It allows a user to grant limited access to its protected resources. Designed to work specifically with Hypertext Transfer Protocol (HTTP), OAuth separates the role of the client from the resource owner. The client requests access to the resources controlled by the resource owner and hosted by the resource server. The resource server issues access tokens with the approval of the resource owner. The client uses the access tokens to access the protected resources hosted by the resource server.
An authorization grant is a credential representing the resource owner’s authorization (to access its protected resources) used by the client to obtain an access token. OAuth 2.0 defines four types of grants.
Code: In this scheme, an intermediate code is provided by the authorization server to the client, which can be exchanged for an access token
Implicit: In this scheme, the client gets the access token directly from the authorization server
Resource Owner Password Credentials: This is used in high trust scenario between client and resource owner where the client can get a direct access token using the resource owner’s username and passwords
Client Credentials: Client credentials are typically used as an authorization grant when the client acts on its behalf (the client is also the resource owner).
Access tokens are credentials used to access protected resources. It is an abstract concept to support different application needs. The token may denote an identifier used to retrieve the authorization information or self-contain the authorization information in a verifiable manner (i.e., a token string consisting of some data and a signature). The most popular format is used JSON Web Token (JWT).
OAuth 2.0 requires client registration with the Authorization Server to authenticate a client approaching the server. This is typically done by registering a callback and secret (optional) with the Authorization Server.
The Authorization server needs to provide two endpoints.
Authorization endpoint — used by the client to obtain authorization from the resource owner via user-agent redirection.
Token endpoint — used by the client to exchange an authorization grant for an access token, typically with client authentication.
Redirection endpoint — used by the authorization server to return responses containing authorization credentials to the client via the resource owner user-agent.
The below diagram depicts the typical scenario of OAuth 2.0 authorization. I believe this is self-explanatory; however, for the completeness of the OAuth 2.0 discussion here, patients like to access their medical records, which are managed by an Electronic Medical Record (EMR) system.
EMR delegated the authentication and authorization to an Authorization Server (Trust Anchor). The client establishes trust with the Authorization server by registering itself by providing a redirection URL and a secret. Each user is expected to have an account in the Authorization server (the authorization server can also delegate this to another party, but for simplicity, we will assume it is available in the same system). EMR trusts access tokens issued by the Authorization server, so before the client can get an access token from the authorization server, it must get a grant from the user to access API on the user’s behalf. Authorization can provide access only by successfully authenticating the user to ensure it is the rightful user trying to access the system. In OAuth 2.0, only the access token is trusted, and EMR has no idea who is trying to access the API. The user ID part of the problem is solved by OIDC, which we will cover in the following article. Till then, enjoy life!!