Understanding Authentication, and Authorization: Fundamentals of Securing Your Applications

Above all, the best way to understand anything is through examples. For instance, imagine we plan to meet at a hotel to start a business together. I arrive at the hotel, and they ask for my identification document. I provide my passport, which they will check to verify that I am who I claim to be. Then, they will confirm my reservation before welcoming me. This process is known as authentication. In exchange for this verification, I will receive a hotel key, which grants me access to my room, the swimming pool, and the fitness room. The hotel key authorizes me to enter these specific areas, and this process is called authorization. In the technology industry, authentication verifies a user or device before allowing access to a system or its resources. Not least, authorization is the process of granting someone permission to access a resource.

Unlocking Identity Security: Dive into OpenID Connect Concepts

To understand OpenID Connect concepts and unlock identity security secrets, is essential to start with other fundamental concepts that form the core foundation of the protocols. Therefore, we will explore the concept of claims, identity provider, and tokens. Claims are personal information about a user, a person, a device, or an entity in general, which are included in security tokens, such as ID tokens in OpenID Connect or access tokens in OAuth 2.0. In addition, claims or resources contain a wide range of data, including user identity, roles, permissions, token information, and custom data. An identity provider is a service that has multiple abilities, among which holds the resources or claims or personal information about the user, implements the OAuth 2.0 and OpenID Connects protocols, and helps the API to check if the user exists and all the claim-based identity is correct to give further access.

There are two choices for using an Identity Provider: We can use a ready-to-go one in the cloud, and there are many products, such as Microsoft Azure ID or Google One, or you can create one yourself. A token is a data unit used in authentication and authorization procedures to confirm system or resource access. It functions as a digital key that substantiates a user’s identity or permits a user to execute specific actions. Moving forward, what is OpenID Connect? OpenID Connect serves as an identity layer built upon the OAuth 2.0 protocol. It allows clients to authenticate the user identity through the processes conducted by an authorization server while also facilitating the retrieval of fundamental profile information about the user in a manner that is both interoperable and aligned with REST architecture.

Mastering OAuth 2.0

OAuth 2.0 & OpenID Connect are becoming the industry’s best practices for solving systems’ authentication and authorization problems. I will give an example as an overview of how these protocols work in practices. Let’s imagine that a user like you or me trusts Google and another application where he wants access to do a specific action. In this case, as a user, you will see a “Connect with Google” button in the application. When the user clicks that button, it will enter the OAuth flow. This is a set of steps that ultimately results in the application where the user can access that information or have permission to do specific actions. So, the user clicks on the “Connect with Google” button and will be redirected to a Google domain, where they will be prompted to log in. In addition, this is one of the best and most secure practices for storing passwords on the internet, I mean not storing at all and using an external service like Google, Facebook or Meta which can store passwords for your application.

Moving forward, the user will be asked for permissions through a dialog after completing the credentials in the Google form. Assuming user approval, the browser redirects back to the application, where the flow did start, and with a little bit of magic, the application is then allowed to talk with Google APIs to authenticate and authorize a user to use the application.

Subtitle: The magic of OAuth 2.0 explained using terminology

In other words, I would like to introduce some essential terms such as:

• Resource Owner: In OAuth 2.0, we have a term called resource owner, which is the user who grants an application permission to access their data,
• Client: The application that wants to access the resource owner’s data,
• Authorization Server: This is the system that I can use to say, yes, I authorized this permission, basically the server which authenticates the user and issues tokens, for example Google, Facebook, GitHub,
• Resource Server: The API or backend which holds the protected resources and validates access tokens,
• Authorization Grant: I will use my past example with Google service, so an authorization grant is proof that the user has granted permissions,
• Redirect URI: Redirect URI or callback, is where the user should end up at the end of the flow,
• Client ID: A unique identifier for an OAuth2 client application,
• Client Secret: A confidential key used by the client app for authentication,
• JWT: Json web token is a compact, self-contained token used for securely transmitting information as a JSON object,
• Authentication: The process of verifying the identity of a user or client application before granting access,
• Authorization: The process of determining what resources a user or application can access.

The call sequence diagram:

User            Frontend            OAuth2 Provider         Backend

|                  |                         |                    |

|—- (1) Clicks ‘Login’ —–>|                         |                    |

|                  |—- (2) Redirect to Provider —–>|                    |

|                  |<— (3) User Authentication —–>|                    |

|                  |<– (4) Authorization Code ——–|                    |

|                  |—- (5) Send Code to Backend —————->|

|                  |                         |—- (6) Exchange Code for Token —>|

|                  |                         |<– (7) Access Token & User Info —-|

|                  |<– (8) JWT Token Response —————|

|—- (9) Store JWT in Cookie ————–>|                    |

|—- (10) Access Protected Resources —–>|                    |

Enhancing Security with OAuth 2.0 Integration

Improving OAuth 2.0 security involves enforcing HTTPS and strong TLS configurations to prevent interception, implementing a proof key for code exchange to protect against code interception, and using short-lived tokens with secure refresh mechanisms. Limit token scopes to the minimum required and validate them on the resource server while ensuring secure token storage in mechanisms like HTTP-only cookies. Validate tokens by checking their signatures, claims, and expiration dates, and enable token rotation with revocation to address compromised credentials. Mitigate cross-site request forgery using OpenID Connect’s state parameter and nonce feature. Finally, OpenID Connect should be integrated to add robust authentication features, such as ID tokens, to strengthen user identity verification. These practices collectively establish a strong foundation for secure OAuth 2.0 implementations.

Conclusion

In conclusion, mastering the essentials of authentication and authorization, using the best approaches in the industry, like OAuth 2.0 and OpenID Connect, is crucial for securing applications. OAuth 2.0 and OpenID Connect enhance identity verification, providing a powerful foundation for third-party authentication. By following best practices, developers can ensure their applications remain secure, scalable, and reliable.

Resources:

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics

https://auth0.com/intro-to-iam/what-is-authorization

https://www.youtube.com/watch?v=996OiexHze0&t=2156s&ab_channel=OktaDev

https://openid.net/specs/openid-connect-core-1_0.html

https://www.youtube.com/watch?v=WGz42L7jo4A&ab_channel=NDCConferences