Modern Authentication and Authorization Protocols

Uncategorized

Modern Authentication and Authorization Protocols

By novicejava1 0

In today’s digital world with distributed microservices based or legacy monolithic applications running on wide variety of platforms there is a need to ensure that only authenticated and authorized users are allowed to access these applications.

Here we will try to understand about the Modern Authentication and Authorization protocols that evolved and how they are leveraging the existing protocols by augmenting on them to address different challenges in the Authentication and Authorization space.

The protocols that we will be focusing more on in this discussion are:

  • Oauth 2.0
  • OpenID Connect

Authentication and Authorization

Before deep diving into the above protocols let’s first try to understand about Authentication and Authorization which are basis for these protocols.

  • Authentication: It is the process of validating whether a person (or system) is actually who they say they are
  • Authorization: It is the process of determining what actions you are allowed to perform once you have been authenticated

Client Server Architecture

The most common architecture of any application whether its monolithic or microservices based architecture is a client-server model.

A client can be any entity that is requesting for some resource and a Server can be any entity that is providing that resource.

The most important factor in making this client-server model based communication to be secure is how we authenticate the identity of the end user or client who is trying to access the resource and whether that entity has all the required permissions to access it.

This seemingly simple communication models implementation gets more complicated as we take into consideration multiple factors such as below.

Resource Types: A resource can be anything from a static file hosted on a webserver to a full fledged web application catering to different domains such as Finance, Insurance, Automobile providing different types of resources hosted on cloud, on-premises or serverless platoform and which can be consumed programmatically using the API’s exposed.

Development Stack: These resources can be developed using different programming languages and frameworks which make it even more complex as each programming languages introduces different set of libraries or modules to use and the complexity varied based on the choice made for this development stack.

Identity Sources: An end user identity can be validated using different sources such as government issued ID cards, Employee issued ID card, Social Account profile information and many more. So we have many sources of identity which adds to this complexity of implementing a secure client-server architecture.

Client types: To add to this complexity we can have different clients trying to access the resource from different platforms such Desktop, Laptop, Mobile or an IoT device to name a few.

So we need a solution which can abstract away some of these factors such providing a single entry point to access multiple identity sources and providing with the user lifecycle management capabilities which eases the activation and deactivation of an end user identity that are used by multiple client applications.

We have many different Authentication and Authorization providers which abrstract away these details and provide us with these services using the protocols built on Open Standards. Some of the terms that we may encounter in our discussion are as shown below.

  • OpenID Connect
  • Oauth 2.0
  • JSON Web Token

Digital Identity

Digital identity is the set of attributes that define a particular user in the context of a function delivered by a particular application. Let’s say if a user is trying to access a banking application, the user attributes consist of his account number, address any other relevant information which can be used to identify him as a banking application user. This same user may possess different set of attributes if he is trying to an social netoworking applications.

Oauth 2.0

Key Components in OAuth 2.0:

  • Resource Owner: The individual or entity that owns the data or resource (e.g., a user).
  • Client: The application requesting access to the resource.
  • Authorization Server: The system that authenticates the resource owner and issues tokens (e.g., Google or GitHub).
  • Resource Server: The server hosting the resource (e.g., an API endpoint).
  • Client Credentials: These are used to authentication a client application
  • Access Token: A credential provided to the client, granting it access to the resource under specified conditions.

Application Interaction before Oauth 2.0

In a traditional Client-Server architecture model, the client authenticaties with his username/password to the server. The server validates the credentials against the credentials store and provides a response of the requested resource.

Let’s assume here the client is the resource owner and the server as the resource server.

Example:

  • Client: Alice
  • Server: Gmail Application

Now Let’s assume there is a new third party application that has been developed by the developer which want to gain access to the above resources provided by the resource server. The third party application developer would provide an authentication page wherein the resource owner can provide his credentials. Once the credentials are shared with the third party application they now ideally have full control on the resources provided by the resource server which was a very bad approach that was followed for years.

Application Interaction with Oauth 2.0

Here we will discuss about two scenarios as shown below.

On Behalf of a Resource Owner

If a user (resource owner) wants an application to access their data, OAuth 2.0 facilitates an Approval Interaction or User Consent between the user and an authorization service (e.g., Gmail, Facebook).

This approval process typically involves:

  • Redirecting the user to a login page of the authorization service.
  • The user authenticating themselves and granting specific permissions (scopes) to the application.
  • The authorization service issuing an access token to the application, which it can use to access the resource.

Imagine you want to use a third-party app to analyze your Spotify playlists:

  1. The app redirects you to Gmail’s login page (authorization service) to authenticate.
  2. You log in and grant the app permission to access your Gmail resources such as user profile, emails.
  3. Gmail issues an access token to the app.
  4. The app uses this token to access your user profile, emails on Gmail’s server (resource server) without needing your password.
  5. By using OAuth 2.0, your password is never shared with the app, and you have control over what permissions are granted.

Application Acting on Its Own Behalf

In this scenario, a backend service (a server or an application running in the background) needs to access another service (such as an API) to perform certain tasks. Instead of relying on user credentials or user involvement, the backend service uses OAuth to authenticate itself and gain access to the required resources. For example:

  • A backend service might use OAuth to authenticate itself to another service (like an API) using its own credentials.
  • This is done via a client credentials flow, where the application directly obtains an access token from the authorization service.

This type of access is achieved using the Client Credentials Flow in the OAuth framework. Here’s how it works:

Imagine a backend service for an e-commerce website needs to calculate shipping rates for customer orders by accessing a third-party shipping API.

  1. Setup: The e-commerce backend service registers with the shipping API provider and obtains a client ID and client secret.
  2. Requesting an Access Token: The backend service sends these credentials to the shipping API’s authorization server and requests an access token with the “shipping rates” scope.
  3. Using the Access Token:
    • The authorization server validates the credentials and issues an access token.
    • The backend service includes the access token in its API requests to fetch shipping rates for orders.
  4. Access Granted: The shipping API verifies the token and grants access, allowing the service to fetch the rates.

This scenario can also be called as Server to Server or Machine to Machine communication where there is no resource owner involvement.

OpenID Connect

OpenID Connect (OIDC) is an identity layer built on top of the OAuth 2.0 protocol. It is used to verify the identity of a user and obtain their basic profile information in a secure and standardized way. OIDC simplifies authentication for developers by allowing them to use a single protocol to authenticate users across different applications and services.

Here’s an overview of OpenID Connect and its components:

Key Concepts in OpenID Connect

  1. Identity Provider (IDP):
    • An entity that authenticates users and issues identity tokens (e.g., Google, Microsoft, Okta, etc.).
    • It ensures that the user’s identity is verified.
  2. Relying Party (RP):
    • The application or service that relies on the identity provider for user authentication.
    • The RP receives and validates tokens from the IDP to grant access.
  3. Tokens:
    • OIDC relies on tokens to communicate user identity and authorization data:
      • ID Token: A JSON Web Token (JWT) that contains information about the authenticated user (e.g., name, email, etc.).
      • Access Token: A token used to access resources (usually from APIs).
      • Refresh Token: A token used to obtain new access tokens without requiring the user to reauthenticate.
  4. Scopes:
    • Scopes define what information the application can request about the user (e.g., `openid`, `profile`, `email`).
    • The `openid` scope is mandatory to indicate that the application is requesting OIDC authentication.
  5. Endpoints:
    • Authorization Endpoint: The URL where the authentication request is sent to start the login process.
    • Token Endpoint: The URL used to exchange an authorization code for tokens.
    • UserInfo Endpoint: The URL used to fetch additional user profile information using the access token.

How OpenID Connect Works

  1. User Initiates Login: The user attempts to log in to an application (the relying party).
  2. Redirect to Identity Provider: The application redirects the user to the IDP’s authorization endpoint.
  3. User Authenticates: The user enters their credentials (e.g., username/password) at the IDP.
  4. Authorization Code Returned: If authentication is successful, the IDP redirects the user back to the application with an authorization code.
  5. Exchange Code for Tokens: The application sends the authorization code to the token endpoint to obtain an ID token and access token.
  6. Token Validation: The application validates the ID token to ensure it is authentic and issued by the IDP.
  7. Access Granted: The application uses the information in the ID token to identify the user and grant access.

Benefits of OpenID Connect

  • Single Sign-On (SSO): Users can log in using a single identity across multiple applications.
  • Standardization: OIDC is a standardized protocol, making it easier to implement and integrate.
  • Security: It uses modern security practices like JWT and HTTPS to protect user data.
  • Interoperability: Works with a wide range of identity providers and applications.

Example Use Cases

  • Social Login: Logging into third-party applications using Google, Facebook, or other social accounts.
  • Enterprise Authentication: Employees accessing internal tools or SaaS applications using a corporate identity provider.
  • Consumer Applications: Streaming services, e-commerce platforms, or mobile apps allowing users to authenticate securely.

OIDC is widely used due to its simplicity, flexibility, and ability to integrate with modern authentication systems.

Hope you enjoyed reading this article. Thank you..