You've probably heard of OAuth 2.0, but have you ever wondered why it's become such a big deal and how it solves some of our authentication headaches? let's dive into it together!

OAuth 2.0 is someone like a loyal mediator that allows different parties to securely share information and resources. It has become the go-to protocol for web service and software companies worldwide, revolutionizing the way we interact and share data. But what exactly does it do?

Imagine this: You're building an application that needs to let users log in with their Google or Facebook accounts. That's where OAuth 2.0 comes to the rescue! It enables federated identity, allowing users to authenticate with one service provider (like Google, facebook) and then use that identity to log in to your app. No more juggling multiple accounts and passwords—your users can enjoy a seamless experience across different platforms. [*note1]

But OAuth 2.0 doesn't stop there. It also solves the problem of delegated authority. Picture this: Your app needs access to a user's Facebook photos or Google contact list. With OAuth 2.0, you can request permission to access those resources on their behalf. It's like having a trusted representative (our loyal mediator) doing the legwork for you. Your app gains the necessary authorization without the user having to disclose their sensitive credentials.

OAuth 2.0 is everywhere, powering the seamless login with Google on StackOverflow, suggesting contacts on LinkedIn, posting on Facebook via mobile apps, and more. ( still usnig facebook? :-)) It simplifies authentication and enables data sharing between apps like Fitbit and health-tracking platforms. From e-commerce to collaboration tools, OAuth 2.0 is our loyal mediator behind the scenes, transforming the way we interact with digital services.

If you want to streamline authentication, enhance user experiences, and unlock the potential of powerful integrations, you need to care about OAuth 2.0 because by combining federated identity and delegated authority, OAuth 2.0 empowers developers to create powerful applications that can integrate, leveraging the capabilities of various services.

Understand simple oAUTH flow

Here are the steps:

1. You ask GoodApp (someone like linkedin) to suggest you contacts.

2. GoodApp says, "Sure! But you'll have to authorize me first. Go here…"

3. GoodApp sends you to Facebook to log in and authorize GoodApp.

4. Facebook asks you directly for authorization to see if GoodApp can access your friend list on your behalf.

5. You say "yes".

6. Facebook happily obliges, giving GoodApp your friend list. GoodApp then uses this information to tailor suggested contacts for you.

image and example reference: Mastering OAuth 2.0 | Packt (packtpub.com)

5 main components of OAuth flow

Imagine in the context where LinkedIn wants our Facebook contacts. Let's understand the components which relate to this example.

1) Resource: This is the actual asset/resource which needs to be shared with the third party app. (Our contacts in the FB are resources)
2) Resource owner (user): This is the user who owns the resource (I am a user of Facebook which means I am the resource owner of my FB contacts).
3) Resource server: This is the server hosting the protected resource, in our case, FB server is the resource server as its hosting our contacts.
4) Client (third-party apps): This is an application requesting access to the protected resource. In our case, Linkedin is the client who wants to access our contacts on FB.
5) Authorization server: This is the server that authenticates the Resource Owner and issues access tokens after getting proper authorization. In our case, it'll be on the FB side.

Important oAUTH Flows

There are 3 important oAUTH implementation flows which play around with the above components.

flow 1) Authorization Code Flow:

The authorization code flow is the most secure and widely used in OAuth 2.0. It involves the exchange of an authorization code for an access token, providing an additional layer of security.
Example: An e-commerce website integrating with PayPal's API, where users are redirected to PayPal for authorization, and upon successful authentication, PayPal redirects back to the website with an authorization code. The website exchanges the code for an access token to process payments on behalf of the user.
refer sequence diagram below :

Pros/Cons Authorization code flow :

• Pros:

  • Enhanced security: More secure due to multiple steps and server-side communication.

  • Supports refresh tokens: Allows obtaining new access tokens without user interaction.

  • Suitable for web applications: The Authorization Code Flow is well-suited for server-side web applications because it allows the client to securely store the client secret and perform the token exchange on the backend, away from the user's browser. This helps protect sensitive information and reduces the risk of exposing the client's secret to potential attackers.

• Cons:

  • Complex implementation: Involves multiple steps, making it more challenging to implement.

  • Requires a backend: Needs a backend component to handle token exchange. The crucial step of exchanging the authorization code for an access token requires server-to-server communication.

flow 2) Implicit Grant Flow:

This is like directly obtaining an access token without an intermediate code exchange.
Example: A mobile shopping app that allows users to log in using their social media accounts. The app utilizes the implicit grant flow to authenticate users with the social media platform and retrieve their profile information for personalized shopping experiences.
refer sequence diagram below :

Pros/Cons Implicit Grant flow :
Pros:

• Simple implementation

• Suitable for client-side applications : It works well for client-side applications like JavaScript-based web or mobile apps, where the client cannot securely store a client secret.

Cons:

• Security concerns : The Implicit Grant Flow poses security risks as the access token is returned directly to the client, potentially exposing it to unauthorized access or interception.

• No support for refresh tokens : which means the client needs to reauthenticate the user to obtain a new access token when the current one expires.

flow 3) Resource Owner Password Credentials Flow (best for Microservices and Trusted Clients):

This flow involves the client directly handling the user's credentials to obtain an access token.
This flow is suitable for highly trusted applications (like internal microservices) where the client and server are under the same control.
Example: A loyalty program app for a fashion retailer where registered users can log in with their username and password. The app sends the user's credentials to the server, which validates them and returns an access token, allowing the app to retrieve the user's purchase history and offer personalized discounts by calling respective microservices using that access token.
refer sequence diagram below :

Pros/Cons resource owner password credentials flow :

• Pros:

  • Simple implementation: Straightforward flow with only one request using user credentials.

  • Direct user authentication: Allows the client to handle the user's credentials directly. (in most of cases a separate user is created, something like user who has only limited access to specific services)

• Cons:

  • Security concerns: The Resource Owner Password Credentials Flow carries a risk of exposure if the client application is compromised. Since the client receives and handles the user's credentials, there is an increased potential for unauthorized access if security measures are not robustly implemented.

We need to choose a flow based on the application requirement and security considerations but all revolve around main 5 components explained.

Summary

Tried to put a basic essential understanding regarding oAUTH 2.0 in this short post.
For more deep details understanding please check the references books and videos suggested at the end.

Understanding OAuth flows is crucial for building secure authentication and authorization systems. While OAuth is primarily an authorization protocol, it can be used for authentication in certain cases. For robust authentication, OpenID Connect-like protocols are recommended, which extend OAuth to provide federated authentication capabilities.

Selecting the appropriate OAuth flow based on application requirements is important. The Authorization Code Flow ensures secure access, the Implicit Flow simplifies client interactions, and the Client Credentials Flow caters to microservices and trusted clients.

Whether you're building a web application or a microservice architecture, understanding OAuth flows and their integration options will empower you to create secure, user-friendly, and efficient systems.

I'll keep learning, experimenting, and sharing my knowledge in the fascinating world of authentication and authorization! stay tuned for the next articles.

Thanks for your valuable time! Thanks for reading! Hope it helps!

Referenes and notes :
Notes :
[*note1] - The OAuth 2.0 protocol is actually an authorization protocol and not an authentication protocol. Because of this, OAuth 2.0 alone cannot provide federated identity. However, when used in a certain way, and in conjunction with other protocols, OAuth 2.0 can provide federated authentication, which is a key component of federated identity systems.

References :
Mastering OAuth 2.0 | Packt (packtpub.com)
OAuth 2.0 Cookbook | Packt (packtpub.com)
https://www.youtube.com/watch?v=t4-416mg6iU&t=10s
https://docs.oracle.com/cd/E50612_01/doc.11122/oauth_guide/content/oauth_flows.html