OAuth and OIDC

Overview

In the traditional authentication methods, the client requests a protected resource on the server by authenticating with the server using the username and password. To provide third-party applications access to restricted resources, the resource owner shares its credentials with the third party.

This creates several problems and limitations. Some of these are listed below:

  1. Third-party applications store the credentials for future use, typically a password in cleartext.
  2. Servers are required to support password authentication, despite the security weaknesses inherent in passwords.
  3. Compromise of any third-party application results in compromise of the end-users’ password and all of the data protected by that password.

OAuth

OAuth addresses these issues by introducing an authorization layer. OAuth 2.0 is an authorization protocol that lets you grant your apps secure access to your resources. Your client is authorized through an Access Token. The access token has a scope that defines which resources the token can access. For more information about OAuth 2.0, see OAuth specification.

While signing up for a new application, if you have allowed to automatically source new contacts using your phone, or Facebook contacts, then you are using OAuth 2.0.

OAuth provides secure delegated access where the application can take actions or access resources from a server on behalf of the user without them having to share their credentials. This is accomplished by allowing the identity provider (IdP) to issue tokens to third-party applications with the user’s approval.

OIDC

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows clients to verify the identity of the end user based on the authentication performed by an authorization server and to obtain basic profile information about the end user in an interoperable and REST-like manner. For more details, see Welcome to OpenID Connect.

While signing up for applications such as YouTube, Jira, Shopping Cart, and so on, you get the option to continue logging in with a well-known Authorization Server/IdP such as Google, Facebook, and so on.

IdPs like Google use Open ID so that users can sign in to the IdP and then access other websites and apps without having to log in or share their sign-in information.
JIRA

Terminology Used in OAuth and OIDC

  1. Resource Owner: A person or system capable of granting access to a protected resource.
  2. Client: An application making protected resource requests on behalf of the resource owner and with its authorization.
  3. Resource Server: The server that hosts protected resources and accepts and responds to protected resource requests using Access Tokens after validating the Access Tokens.
  4. Authorization Server: The server that issues Access Tokens to client apps after successfully authenticating the resource owner.
  5. Client_id: It is a unique identifier assigned by the authorization server to the application registered with it.
  6. Client_secret: The client_secret is a secret known only to the application and the authorization server.
  7. Authorization Code: The authorization code is a temporary code that the authorization server issues to the client. The client will exchange it for an Access Token in the subsequent requests.

OAuth Roles

OAuth defines four roles:

  1. Resource Owner
  2. Resource Server
  3. Client
  4. Authorization Server

Note: NSX Advanced Load Balancer (also known as Avi) supports Client and Resource Server roles.
NSX Advanced Load Balancer cannot act as either Client or Resource Server. It can act as a Client and Resource Server. Being a client and resource server, NSX Advanced Load Balancer will get the authorization code from the end user, exchange the authorization code with the Access Token, validate the Access Token, allow the client to access the resource based on the token validation and authorization policies based on the claims.

OAuth Grants for Obtaining Authorization

The OAuth 2.0 Authorization Framework supports several different flows (or grants). Flows are ways of retrieving an Access Token. To request an Access Token, the client obtains authorization from the resource owner. The authorization is expressed in the form of an authorization grant which the client uses to request the Access Token.
OAuth defines four grant types:

  1. Authorization Code
  2. Implicit
  3. Resource Owner Password Credentials
  4. Client Credentials

Note: NSX Advanced Load Balancer supports Authorization Code Grant Flow only.

Authorization Code Grant Flow

The flow of the Authorization Code grant type is explained below:

Authorization Code Grant Flow

  1. The resource owner accesses the app/client and triggers authentication and authorization.
  2. The client redirects the user to the authorization server where it prompts the user for their username and password. On this page, the resource owner can choose permissions to authorize the client to access resources on their behalf.
  3. The authorization server receives the authentication and authorization grant.
  4. After the resource owner authorizes the app, the authorization server sends an authorization code to the client using a redirect.
  5. The client uses the authorization code to request an Access Token from the authorization server.
  6. The authorization server validates the authorization code and issues an Access Token. If OIDC is enabled, then ID token is also issued along with Access Token.
  7. The client attempts to access the resource from the resource server by presenting the Access Token.
  8. If the Access Token is valid, the resource server returns the resources that the user authorized the client to receive.

Different Types of Tokens

  1. Access Token: Access Tokens are credentials used to access protected resources. An Access Token is a string representing an authorization issued to the client. The Access Token can be of two types – JWT (JSON Web Token) or Opaque Tokens. In the case of JWT, the resource server can validate the Access Token on its own, whereas in the case of the Opaque Token, the resource server talks to the authorization server on /introspection endpoint to validate the Access Token.

  2. Refresh token - Refresh tokens are issued to the client by the authorization server and are used to obtain a new Access Token from the authorization server when the current Access Token becomes invalid or expires. Here is the flow diagram explaining how the expired Access Token is refreshed:
    Refresh Token

  3. ID token: This is used if OIDC is enabled on the client. This token is returned by the authorization server, and it encodes the user’s authentication information.

Different Types of Endpoints

  1. Authorize/Authorization endpoint – This endpoint is used by the client to obtain authorization from the resource owner through user-agent redirection.
  2. Token endpoint – This endpoint is used by the client to exchange an authorization grant for an Access Token. The same endpoint is used to get the refresh token and the ID Token (in the case of OIDC).
  3. Redirection endpoint/Redirect URL/Call back URL – This is used by the authorization server to return responses containing authorization credentials to the client through the resource owner user-agent. This is most commonly known as Call back URL.
  4. Introspection endpoint – The introspection endpoint is mostly used for validating the Opaque Access Tokens. For Opaque Access Tokens, the resource server sends the request to the introspection endpoint of the authorization server to validate the Access Token.
  5. UserInfo endpoint - The UserInfo endpoint can be used to retrieve identity information about a user. This is used in the case of OIDC. To obtain the requested claims about the end user, the client requests to the UserInfo endpoint using the Access Token obtained.

Related Article

Client and Resource Server for OAuth/OIDC