When you request to login on a server, you are redirected to the 3rd party server like Google (Sign in with Google), and you login in with your Google account. Have you ever wondered how is the company utilizing your google account to login to their server and how is the Auth provider able to provide this service.

In this blog we will see both of the perspectives

• Company’s (Client’s) perspective.

• Auth Service Provider’s perspective.

Perspective of a Server who is utilizing the 3rd Party Auth Service.

In this part we will se the perspective of the Server who is utilizing the 3rd party auth service.
Eg. Suppose a company ram.com wants to utilize the Google Auth Service to handle their user Auths.

Please refer to the diagram as well for better understanding.

• 

NOTE - This is just a high level overview, and the flow doesn’t focus on Security yet. We will cover it in later part of the blog while discussing the Auth Provider’s perspective. Please keep referring to the diagram while reading the steps.

1. User initiates login → We (ram.com) will redirects user to Authorization Server (1)

2. Auth Service gives us Authentication Token with Stamp (private key encryption) (2)

3. We (ram.com) retrieve the public key from the route that Auth Service Provider has exposed.[jwks_uri ] (3)

4. Our server then Verifies the token through the public key we got. (4)

5. If the token is valid we will retrieve the user data from DB and returns the response. (5)

Perspective of an Auth Service Provider who is providing the Auth service to its clients.

Step 1. User initiates login

Step 2. Client redirects user to Authorization Server (/authorize)

• Client will send Client id, redirect_uri, etc.. to the Auth Server.

• User Authentication on Authorization Server
  User enters credentials (email/password).

  Authorization Server verifies: Credentials correctness.

Step 3. Auth Server will create an Authorization code

• Auth Server will give an Authorization code to the Client

Step 4. Client will then sends the client Secret and auth code to Auth provider (/token)

• Auth Provider will verify the Client with Client Secret and auth code.

Step 5. Auth Server issues tokens ( Access token , ID Token, Refresh Token)

• Among the tokens, the id_token represents the authenticated user.
  id_token is also jwt signed and Its payload contains these info

  • iss = the issuer ( i.e. the Auth server)

  • aud = the audience/who requested it (i.e. the client)

  • sub = the subject (i.e. the user)

  • iat = issued at

  • exp = expiration time

• The Access token and refresh token represents the client.

• Auth Server returns the tokens to the client.

Step 6. Client Frontend sends the token to the backend for verification of the token.

Step 7. Client Server gets the public key from Auth Server [/jwks_url].

• This public key is essential for verifying the token authentication.

Step 8. Verifies the token using public key sends a request to AuthService provider to get the user login info. (/userInfo)

• Response is send to the user.

---

Note - This article is crafted based on the limited information available on internet. Please do your own research to verify the information in the blog.

Thank you for reading!