Introduction to OAuth2.0 and OIDC

🧬 Introduction

In the early days of the Internet, sharing information was done simply by providing your username and password so that it would fetch the information they wanted. But the issue with providing credentials is that it does not guarantee that they will be kept secret by that service, or they will not access your personal information that you do not want to share.

However, nowadays we have industry standard protocols to ensure the access delegation is done properly so that the services won’t get unnecessary access.

🧪 OAuth 2.0

OAuth 2.0 is such an industry standard that you give one application/service permission, or consent to access your data in another application. These steps to grant permission or consent, are often referred to as authorization or delegated authorization. In this way, you give one application to access your data or use features in another application without providing your credentials.

〰️ OAuth2.0 Flow

To get an understanding of how OAuth2.0 works, we need to understand a few terms involved with the OAuth2.0 flow.

• Resource Owner
  ↳ You are the resource owner in the OAuth2.0 flow. There can be resources you own like images, videos, etc.
• Client/Application/Relying Party
  ↳ The application that wants to access data or perform actions on behalf of the Resource Owner.
• Authorization Server
  ↳ The application that knows the Resource Owner, where the Resource Owner already has an account.
• Resource Server
  ↳ The API or service the Client wants to use on behalf of the Resource Owner.
• Response Type
  ↳ The type of information the Client expects to receive. The most common response type is code, where the Client expects an Authorization Code.
• Scope
  ↳ These are the permissions that the Client wants, to access data or perform actions.
• Consent
  ↳ The Authorization Server takes the Scopes the Client is requesting, and verifies with the Resource Owner whether or not they want to give the Client permission.
• Client ID
  ↳ This ID is used to identify the Client with the Authorization Server.
• Client Secret
  ↳ This is a secret password that only the Client and Authorization Server know. This allows them to securely share information privately behind the scenes.
• Authorization Code
  ↳ A temporary code, the Client gives to the Authorization Server in exchange for an Access Token.
• Access Token
  ↳ The key the client will use to communicate with the Resource Server. This allows the Client to request data or perform actions with the Resource Server on your behalf.

Now let’s look at the OAuth2.0 flow.

1. You, the Resource Owner, want to allow the Client application to access your data.
2. The Client redirects your browser to the Authorization Server and with that request, it sends the Client ID, Redirect URI, Response Type, and one or more Scopes it needs.
3. The Authorization Server verifies who you are, and if necessary it prompts for a login.
4. The Authorization Server presents you with a Consent form based on the Scopes requested by the Client. You can grant or deny the permissions.
5. The Authorization Server redirects back to the Client using the Redirect URI along with an Authorization Code.
6. The Client sends a request directly to the Authorization Server (without using the Resource Owner’s browser) with the Client ID, Client Secret, and the Authorization Code.
7. The Authorization Server verifies the data and responds with an Access Token.
8. The Client can now use the Access Token to send requests to the Resource Server and acquire the data, the Resource Owner is given access to.

🔋 What is OpenID Connect?

Although OAuth2.0 provides authorization, one of the main flaws is it does not provide any information on the Resource Owner’s Identity.OpenID Connect(OIDC) is a thin layer that sits on top of OAuth2.0 that adds login and profile information about the person who is logged in.

Establishing a login session is called authentication, where you verify the information about you (or your identity) when you try to log in. When an Authorization Server supports OIDC, it is sometimes called an Identity Provider, since it provides information about the Resource Owner back to the Client.

The most important fact about OIDC is that it enables scenarios where one login can be used across multiple applications, also known as single-sign-on(SSO). For example, an application could support SSO with social networking services such as Facebook or Twitter so that users can choose to leverage a login they already have and are comfortable using.

🎭 Differences between Authentication and Authorization

While often used interchangeably, authentication and authorization represent fundamentally different functions. In simple terms, authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to.

Here’s a quick overview of the differences between authentication and authorization.

Authentication

1. Determines whether users are who they claim to be
2. Challenges the user to validate credentials (e.g. through passwords, facial recognition, etc.)
3. Usually done before authorization
4. Generally, transmits info through an ID Token
5. Generally governed by the OpenID Connect(OIDC) protocol

Authorization

1. Determines what users can and cannot access
2. Verifies whether access is allowed through policies and rules
3. Usually done after successful authentication
4. Generally, transmits info through an Access Token
5. Generally governed by the OAuth2.0 framework

〰️ OpenID Connect Flow

The OpenID Connect is similar to the OAuth2.0 flow. The only difference is that a specific scope of openid is used and due to that in the final exchange, the Client receives both an Access Token and an ID Token.

The ID Token is a specifically formatted string of characters known as a JSON Web Token or JWT. The JWT Token has three parts.

• Header
  ↳ The header typically consists of two parts; the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256, or RSA
• Payload
  ↳The payload contains the claims. The claims are statements about an entity(typically, the user) and additional data. There are three types of claims: registered, public and private.
• Signature
  ↳ To create the signature part, you need to take the encoded header, the encoded payload, a secret, and the algorithm specified in the header. This is used to verify that the message wasn’t changed along the way.

These parts are separated by dots as header.payload.signature

📦 OAuth2.0 Grant Types & WSO2 IS

In OAuth2.0, the term Grant Type refers to the way a client application acquires an access token depending on the type of the resource owner, the type of the application, and the trust relationship between the authorization server and the resource owner.

WSO2 IS, or WSO2 Identity Server is an on-premise Identity and Access Management Solution offered by WSO2. The grant types offered by WSO2 IS are shown below.

• Authorization Code Grant Type
• Implicit Grant Type
• Password Grant Type
• Client Credentials Grant Type
• Refresh Token Grant Type
• JWT Baerer Grant Type
• SAML2 Bearer Grant Type
• Kerberos Grant Type

In addition, we can create custom grant types according to our use cases. 😎

In the upcoming articles, we will be looking at grant types and the other services that OIDC offers in greater detail. Till then happy learning!

📚 References

• https://developer.okta.com/blog/2019/10/21/illustrated-guide-to-oauth-and-oidc
• https://auth0.com/docs/get-started/identity-fundamentals/authentication-and-authorization
• https://is.docs.wso2.com/en/latest/references/concepts/authorization/grant-types/