OIDC & Blockchain: Most Secured Identity System on Planet
PART — 1
Authentication & Authorization
Every application on web/mobile mostly requires some sort of user authentication and authorization. We have several ways to achieve authentication and authorization (access control for different kinds of users). It varies from simple user sign-in using username/password and maintaining a session on server side using session ID stored in browser cookies to JWT (Json Web Token) based approach.
Authentication & Authorization (A&A) go hand-in-hand. Let’s understand in comprehensible terms what differentiates Authentication and Authorization.
Authentication = Is user allowed to access the application at all?
Authorization = Is user allowed to access the feature / resource of the application?
OpenID Connect
OIDC (OpenID Connect) is the protocol that standardizes the authentication and authorization process by connecting OpenID and OAuth 2.0. OpenID is the protocol for authentication and OAuth is the protocol for authorization. OIDC is the revamped protocol that connects OpenID and OAuth both to achieve authentication and authorization.
In other words, OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol, which allows computing clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user in an inter-operable and REST-like manner. In technical terms, OpenID Connect specifies a RESTful HTTP API, using JSON as a data format.
OIDC = Authentication (OpenID) + Authorization (OAuth 2.0)
Why OIDC?
SAML (Security Assertion Markup Language) and OIDC are two standards for Single Sign On (SSO). SAML is slightly old technology that leverages XML messages between parties which is much heavier in size than OIDC token which is formatted as JWT (Json Web Tokens) .
Also, SAML Token (called Assertion) is not meant for API security where as OIDC has access token for API security in addition to ID token which is analogous to SAML Token.
With most of the modern API security architecture supporting OAuth2 scopes, OIDC is the preferred protocol since it is built on top of OAuth2 authorization protocol that supports consent flow also.
OIDC Components
- Relying Party or OIDC Client Initiates the Authentication flow with OIDC Provider
- OIDC Provider is the Identity Provider which provides various Authentication flows to authenticate user securely and after successful authentication provides ID Token, Access Token and optional Refresh Token to Relying party.
- Resource provider validates the access token and also authorize user if the end user is allowed to access the resource based on the claims set in access token.
A brief about OAuth
OAuth is standard for authorization. It provides secured delegated access to client application for user data managed by identity provider.
For example if any application (say “App1”) needs some user information that is available in third party application (Identity provider). Then “App1” can ask for consent from end user using oAuth protocol to obtain required user information (claims) from third party applications.
In order to build the trust between the parties , the client application (“App1”) needs to be registered on Identity Provider and information like Client Id and Secret is shared with the client application.
OIDC Endpoints
The major endpoints are mentioned below , which is provided by OIDC Provider
OIDC Scope and Claims
Claims are nothing but a basic unit of user information,
For example : given_name, family_name, email, phone_number, etc.
Scope on the other hand is a group of Claims that can be asked as a consent from end user while initiating OIDC flow.
For example : we can configure profile as a Scope to get the consent for accessing “given_name”, “family_name”, “name” Claims together.
OIDC Flows
As OIDC is built over oAuth 2.0. It shares the similar flow but with some changes.
OIDC has basically three flows:
1. Authorization Code Flow
2. Implicit flow
3. Hybrid flow
1. Authorization code flow
The OpenID Connect authorization code flow illustrates how the relying party interacts with the OpenID provider (OP), when requesting an authorization code.
The authorization code flow ensures that the client application and not the end user’s browser, handles the tokens.
The authorization code is then exchanged for an ID token, access token, and refresh token from the token endpoint. The authorization code flow also defines how the relying party can validate claims about the end user and get additional information about the end user from the userinfo endpoint using the access token.
The below sequence diagram summarizes the entire functionality.
2. Implicit flow
The implicit flow allows clients, such as mobile applications, to interact directly with the OpenID provider, OP, and receive tokens directly from the authorization endpoint and not from the token endpoint.
The following sequence diagram shows successful processing from the authorization request through grant of the access and ID tokens from the authorization endpoint, and optional use of the access token to get information about the end user from the userinfo endpoint:
3. Hybrid Flow
The hybrid flow allows the end user’s browser to gain access to short-lived tokens, such as ID tokens, and to use the authorization code to obtain long-lived tokens, such as refresh tokens.
The following sequence diagram shows successful processing from the authorization request, through grant of the authorization code, access and/or ID tokens depending on the resource type, and optional use of the access token to get information about the end user:
That’s all folks!
I hope so far you have understood the working of OIDC and felt its power to secure the identity of the user. At DLT Labs, we use the combination of Blockchain and OIDC to secure all our products and customer PII data. We will be publishing more on this topic soon.
Author — Divesh Pal, DLT Labs™
About the Author: Divesh Pal is a tech enthusiast working with DLT Labs as a Technology Lead, and has a broad experience in various domains such as Travel, Enterprise mobility, and Health care. He has expertise in designing and developing cloud-centric distributed web applications.
