Understanding concepts like digital identity, encryption, and authorization protocols is crucial in today’s digital landscape. This article aims to shed light on these topics and provide a comprehensive overview.

In the digital world, a digital identity uniquely represents an entity, be it an individual, organization, or device. Just as physical identity attributes like your name, photo, and personal information help identify you in the physical world, digital identity consists of unique digital attributes such as usernames, email addresses, biometric data, and digital certificates.

These digital identifiers are used to establish and verify your identity in the digital realm, allowing you to access online services, communicate securely, and conduct various activities in the digital world.

This parallel between physical and digital identity highlights the importance of secure and reliable identification methods in both domains. This can manifest as usernames, emails, public keys, or even biometric data. These identifiers play a pivotal role in verifying one’s identity in the digital realm.

Encryption

• Converts plain text into cipher text using a mathematical algorithm and an encryption key.
• It is a two-way process.
• Unlike hashing, it does not result in a fixed-length output.

Hashing

• Converts plain text into a fixed length string of chars called hash.
• A good hash should be a one-way process, meaning once the data is hashed, it cannot be easily reversed to obtain the original input.
• Used to check data integrity
• Fixed length

Let’s talk about a few questions:

Is Bcrypt hashing or encrypting?

Answer: Even if the name includes crypt and suggests encryption, it is hashing.

Is Base64 hashing or encrypting?

Answer: Neither, it is encoding. It is an encoding technique used to represent binary data in an ASCII string format. It’s commonly used for tasks like encoding images in email attachments or embedding binary data in URLs.

Authentication: Verifying if a user is who they claim to be

Authorization: Verifying if the user has access to resources the resource they want to access.

Tokens are pivotal in managing access and identity in the digital world. They serve as data representations of a user’s identity or provide access to specific resources.

Various tokens exist, including access, refresh, session, ID, and CSRF. Each of them is discussed below:

1. Access token: The client uses this token to access the Resource Server (API). They are meant to be short-lived. These tokens are usually valid for a few hours or a day. As it has a shorter period, it cannot be revoked. Instead, we have to wait for this token to time out.
   If you’re using an access token with a secure API, give the access token a shorter time out to adhere to security best practices. For example, the time out can be an hour.
   OAuth2.0 can be used for authorization, allowing you to access a resource such as an API endpoint for CRUD operations.
2. Refresh token: The client uses the refresh token to get an access token. To get a refresh token, applications typically require confidential clients with authentication. This is much longer-lived: days, months, or years. This can be revoked at any time.
3. Session token: Token used to maintain stateful interactions between the client and server.
4. ID token: Used strictly for authentication using OIDC.
5. CSRF token: Used to prevent a specific type of attack where a user is tricked into acting on a different website without their knowledge.

Tokens do not have to be in the form of JWTs (JSON Web Tokens). While JWTs are a popular choice for tokens due to their compact size, self-contained nature, and ease of use, they are not the only option.

OAuth 2.0 and OpenID Connect (OIDC) serve distinct functions. OAuth 2.0 is primarily an authorization framework, while OIDC is geared towards authentication. OIDC operates atop OAuth 2.0, which is built on top of HTTP.

OAuth 2.0 and OpenID Connect (OIDC) are different techs built for different purposes.

OAuth 2.0 is an open-standard authorization framework, not an independent service. It enables you to grant delegated permissions and allow access to specific resources such as profile pictures, emails, and phone numbers. It is read as “oh-auth,” and it’s not the same as AuthO, which is read as “auth-zero.” One is a protocol specification, and the other is a product.

OAuth maintains several roles that help facilitate and delegate access to protected resources.

1. Resource Owner (RO): An entity that can grant access to a protected resource. The user can be a system or an application. They only need to own the data in the resource server. For example, I’m the resource owner of my Facebook profile.
2. Client: The application that wants to access protected data on behalf of the resource owner. A mobile app that wants to access a user’s photos on a cloud storage service. (e.g., web or mobile app). This is a bit controversial. From the auth server perspective, any app tries to authenticate its client.
3. Resource Server (RS): The server that hosts the protected resource. It verifies the token and provides access to the resource. (e.g., server hosting file)
4. Authorization Server (AS): Server responsible for authenticating the resource owner and obtaining their consent to grant access to the client. Once it’s done, it issues an access token to the client (e.g., GitHub, Facebook, and Linkedin. They all operate their own authorization server)
5. Authorization grant: Credential representing the resource owner’s consent to allow the client to access their resource. There are different types of grant auth codes: implicit, client credential, etc.
6. Redirect URI: After the owner grants permission, the authorization server redirects users back to the client as a specific URL with authorization information. This is generally called callback URL
7. Access token: Credential that represents that the authorization has been granted. They cannot do everything, only the things defined in the scope
8. Refresh token: Optional. Used to get a new access token in case the previous one expires
9. OAuth scopes: It specifies the level of access a client can be granted. It is maintained and defined in the authorization server

• Simplicity: Version 1.0 was intricate due to its reliance on cryptographic signatures for each request.
• Support: Initially tailored for server-to-server communication, version 1.0 has evolved to accommodate a broader spectrum of clients, including mobile apps, web apps, and IoT devices, thanks to the introduction of various grant types.
• Native support: Version 1.0 was not optimally suited for native mobile applications. Version 2.0 addressed this by introducing PKCE (Proof Key for Code Exchange), enhancing the security of authorizations.
• Token-Based: While version 1.0 relied on signature-based authentication, version 2.0 adopted a bearer token approach, streamlining the authentication process.
• Scope: Unlike version 1.0, which lacked a standardized method for managing permissions and scope, version 2.0 introduces scopes, allowing for more precise and granular access control.

OAuth flows or grants, are a mechanism for clients to get credentials from authorization server (AS) to access the resource server (RS). OAuth offers various flows tailored for different scenarios, including Auth code flow, Implicit flow, Client credential flow, Auth code with PKCE, and Resource owner password grant flow.

Usage: Used by a web or server-side app that can securely store client secrets.

It’s applicable to web or server-side applications with the capability to securely store client secrets, specifically when control over both the front and back channels is maintained.

Here’s the steps to follow:

1. Client redirects the resource owner to the authorization server endpoint
2. Resource owner authenticates and authorizer the client access request
3. Authorization server responds with authorization code
4. Client exchanges an authorization code for an access token

Usage: suitable for client-side apps that cannot securely store client secrets

Here’s the steps to follow:

1. Client redirects to RO’s AS endpoint
2. RO authenticates and authorizes the client access request
3. AS responds with an access token

While the Implicit Grant flow was once widely used, it’s now considered less secure due to potential vulnerabilities (access token send via query param, no refresh token, etc.). As a best practice, it’s recommended to steer away from utilizing the Implicit Grant flow. Instead, consider adopting the Auth Code Grant flow with PKCE (Proof Key for Code Exchange).

This enhanced approach offers a more robust and secure method for authorization, providing an added layer of protection against potential threats. Your application’s security and integrity are paramount, and making this switch is a step in the right direction.

Usage: used for server-to-server communication (back channel only). The Client Credential Flow is utilized for server-to-server communication, where the client application needs to authenticate itself to access a protected resource. This flow is appropriate when there is no direct user involvement and the client application can securely store its own credentials.

Here’s the steps to follow:

1. The client application sends its own credentials (client ID and client secret) directly to the authorization server’s token endpoint.
2. The authorization server verifies the provided credentials and, if valid, issues an access token directly to the client.
3. The client can now use this access token to access protected resources on the resource server.

Usage: Enhanced version of auth code to protect against attacks

Here’s the steps to follow:

1. It is the same as an auth code grant but includes a step to generate a challenge
2. The client generates a one-way hash
3. The challenge is used to prove the possession of the original code during a token exchange

Usage: This flow is typically used when the client application has direct access to the user’s credentials and can securely store them. It’s commonly seen in legacy or internal systems where higher security measures may not be required.

Here’s the steps to follow:

1. The client application prompts the user for their username and password.
2. The client sends the user’s credentials (username and password) directly to the authorization server’s token endpoint.
3. The authorization server validates the credentials and, if they are correct, issues an access token directly to the client.
4. The client can now use this access token to access protected resources on the resource server on behalf of the user.

OpenID Connect is dedicated to authentication, offering a standardized approach to areas where OAuth 2.0 leaves room for interpretation, such as scope and endpoints.

It extends OAuth 2.0, which allows clients to verify the identity of the end user and obtain basic profile information.

Some key things we should remember about OIDC are:

• OIDC extends OAuth 2.0.
• OpenID is a simple identity layer on top of OAuth 2.0.
• It allows clients to verify the identity of the end user based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the end user.
• OIDC generally uses JSON Web Tokens (JWTs).

OAuth primarily facilitates resource sharing and access, whereas OIDC specializes in user authentication. Its primary objective is to provide identity verification across multiple websites.

When using OIDC to log in to a website, you are redirected to the OpenID site for authentication. Once authenticated, you are then redirected back to the original website. For instance, if you opt to sign in with Google, you’ll first encounter the Google login form. Upon successful login, you’ll be directed back to your web application.

This redirection process ensures you receive a secure JWT token for further authentication and authorization.

The decision to use OpenID Connect (OIDC) or OAuth 2.0 depends on the specific requirements of your application. Here are a few use cases:

Simple login auth

• Identity: OIDC
• Type: Authentication

Single sign-on across sites

• Identity: OIDC
• Type: Authentication

Mobile app login

• Identity: ODIC
• Type: Authentication

Delegated authorization

• Identity: OAuth.20
• Type: Authorization

Here are some recommendations on where to use what flow:

1. Auth code flow

• Usage: Suitable for web applications or server-side applications that can securely store client secrets. This applies when you have control over both the front and back channels.
• Example scenario: A traditional web application with a backend server, Native app like mobile apps.

2. Implicit flow

• Usage: Appropriate for client-side applications that cannot securely store client secrets. This applies when you only have access to the front channel, but not the back channel.
• Example scenario: A Single-Page Application (SPA) or a mobile app.

3. Client credential flow

• Usage: Used for server-to-server communication where the client can securely send client credentials (client ID and client secret) to the Authorization Server’s endpoint.
• Example scenario: Communication between two servers or backend services (API to API), daemons

4. Auth code with PKCE

• Usage: An enhanced version of the Auth Code Flow, particularly designed to protect against certain attacks.
• Example scenario: Mobile apps, native apps, or any scenario where you want to add an extra layer of security to the authorization process.

5. Resource owner password grant flow

• Usage: Typically, for backend systems where the resource owner (user) trusts the client with their credentials. This flow is considered less secure and should be used sparingly.
• Example scenario: Internal systems or legacy applications, native apps, headless clients like CLI apps

Remember, the choice of OAuth 2.0 flow depends on your application’s specific requirements and security considerations. It’s essential to understand the strengths and weaknesses of each flow to make an informed decision.

Here are some of the use cases and their recommended flow types:

Web apps want to access API (FE + BE)

Flow type to be used

• Authorization code flow
• Hybrid (implicit + code flow)
• Can add a refresh token flow
• Machine-to-machine flow

Mobile apps

Flow type to be used

SPA

Flow type to be used

• Authorization code grant flow

CLI apps or Daemons

Flow type to be used

API-to-API

Flow type to be used

• Client credential flow
• User will be in trusted systems

SSO with third-party service

Flow type to be used

• Better integrate with OKTA/Auth0/PingID

In wrapping up, it’s evident that a clear distinction exists between the usage scenarios of OAuth 2.0 and OIDC. As engineers, we must discern these differences and apply them judiciously according to our specific needs.

This nuanced understanding empowers us to navigate the digital landscape effectively, ensuring that our applications are secure and functional. Remember, it’s not about circumventing the use case but rather about leveraging the right tool for the job.

I hope this overview of digital identity, encryption, OAuth 2.0, and OIDC has provided you with valuable insights into securing your online interactions. Understanding these concepts is essential in today’s digital landscape.

Thank you for taking the time to read our article! If you found this information helpful, don’t hesitate to leave a comment and consider sharing it with others who might benefit from it.

Stay safe and secure in your digital endeavors!

To debug OIDC requests: