Independent Auth Service

The outlined technical document provides a comprehensive explanation of the Authentication and Authorization flow within the described system. It follows a standard OAuth 2.0 authorization framework. Here's a breakdown of the key components and their interactions:

• Auth Service: Serves as an independent microservice responsible for generating Authorization codes, Access tokens, and Refresh tokens.Validates user details during the login process and returns an authorization code and redirect URL.Manages the regeneration of access tokens using refresh tokens.
• Client Application: Represents any client-side application (Angular, React, Vue.js, Android, iOS), Initiates the authentication process by calling the Auth Service's login API and handles the redirection to the provided URL and subsequent calls to the Auth Service to obtain Access and Refresh tokens. Stores the Access token in cookies and encrypts the Refresh token for storage in Local Storage.
• Resource API: Represents an API for business logic that is accessed by client applications with a valid Access token.Validates the provided Access token and returns false if it has expired (20-minute expiration).

Authentication and Authorization Flow:

1. Customer initiates the process by hitting the Login API with a username and password.
2. Client Application calls Auth Service to obtain an authorization code and redirect URL.
3. After redirection, the client calls Auth Service to exchange the authorization code for Access and Refresh tokens.
4. Access token is stored in cookies, and the encrypted Refresh token is stored in Local Storage.
5. Client Application accesses Resource API using the Access token. If the Access token expires, the client calls Auth Service with the Refresh token to obtain a new set of tokens.

Access to Another Client Application:

1. Client Application 1 wants to access Client Application 2.
2. Client Application 1 calls Auth Service with its Access token and the desired client scope ("client application 2").
3. Auth Service returns a new authorization code and redirect URL if the user has access to "client application 2".
4. Client Application 1 redirects to the URL of Client Application 2 with the obtained authorization code.
5. Client Application 2 calls Auth Service to exchange the authorization code for Access and Refresh tokens.
6. The Access token is valid for 20 minutes and is unique to each client application.

This design ensures secure and controlled access to resources, facilitates token regeneration, and allows for scoped access between different client applications. It follows best practices for authentication and authorization in a distributed system.

Access Token

Access tokens are credentials that are used to access protected resources.

• When a client (an application or user) presents an access token to a server managing a resource, the server uses the information embedded in the token to determine whether the client is authorized to access the requested resource.

Token Content and Authorization:

• Access tokens contain information such as user identity, scope, and any other necessary details that the resource server requires to make an authorization decision.
• The content of the access token is usually in a structured format like JSON, containing relevant claims and information about the authentication context and for that we can use JWT

Expiration and Short-lived Nature:

• Access tokens typically have an expiration date or time-to-live (TTL) associated with them.
• The short-lived nature of access tokens enhances security by minimizing the risk in case of token leakage or unauthorized access. If a token is intercepted or obtained by an attacker, its usefulness is limited by its expiration time.

Refresh Tokens:

• Refresh tokens are designed to obtain a new access token from the authentication server when the current access token expires or when a new one is needed for a different resource.
• They enable clients to refresh their access without requiring the user to re authenticate.

Long-lived Nature:

• Refresh tokens are usually long-lived compared to access tokens. While access tokens have a short expiration time, refresh tokens are designed to be valid for a more extended period.

Expiration and Blacklisting:

• Although refresh tokens have a longer lifespan, they are not indefinite. They can also expire, and their expiration policies should be defined by the authentication server.
• Authorization servers may maintain a blacklist to revoke compromised or invalidated refresh tokens, enhancing security.

In summary, access tokens play a crucial role in enabling secure and controlled access to resources in distributed systems. Their short-lived nature and embedded information contribute to the overall security of the authentication and authorization process. Refresh tokens serve a critical role in maintaining continuous access to resources by enabling the secure renewal of access tokens. Their long-lived nature, along with security measures such as storage requirements and potential blacklisting, contributes to the overall security of the token-based authentication system.

Database Structure of Auth Service

Uses of Auth service is always depends of application's scope. So here let's describe the configuration of auth service -

In my next tech article, I will come with Service contract and codebase .

Happy coding :)