Every time we authenticate, it’s not necessary to do it for every microservice. For example, let’s say we have a user management service that handles sign-up, login, password recovery, and token validation.
Imagine we’re searching for something. First, we try to log in by sending a request to the user service. If the login is successful, we receive a token. We then send this token to the search page. The search page sends another request to validate the token, using the validateToken API in the user service. If the token is valid, we receive a response, and we redirect the user to the search page.
Now, suppose we have multiple services that need validation, all of them sending requests to the user service to validate the token.
Oauth -> Many websites offer sign-up options through Google and Facebook to quickly authenticate users. But how does this work when they’re using third-party APIs for authentication?
Here lies a challenge: each OAuth provider, like Google or Facebook, has its own way of handling logins and sign-ups. Writing code for all of them can be difficult. To address this,there’s a solution: OAuth protocols. OAuth is an industry-standard protocol for authorization, much like REST is for APIs.
To implement OAuth, we need to follow its protocols. OAuth provides an API contract (or interface) for authorization, making it easier to establish consistent authentication mechanisms across different platforms.
How does OAuth work?
OAuth involves four main participants:
- User: This is the person or client seeking access to a resource.
- Resource server: This server holds the information that the user wants to access.
- Application: This is the service through which the user is attempting to access something.
- Authorization server: This service manages the authentication process.
Let’s understand this with a simple example. Suppose we want to access a specific course topic, let’s say “/topics/course/1”, and we’re logging in via Google. When we log in using Google, we’re redirected to a popup on the Authorization server, which is part of our website or application. Here, we provide our Google credentials. Then, we receive a response indicating whether the login was successful or not. All the resources we’re accessing are within our application, so it’s also considered the resource server. In this scenario, I, as a user, am trying to authenticate.
In Case 1, where the application is also the resource server, the login request goes directly to the application. The application then sends a request to the authorization server. After a successful login, you receive a token.
In Case 2, where the application server and resource server are different, the login request goes to the application server first. The application server then calls the authorization server, which returns the token. Afterward, the application server makes another request to the resource server using this token. If the resource server can’t validate the token, it calls the authorization server. If the token is invalid, you’re signed out immediately. If it’s valid, the data is returned to the application server.
