SSO Authentication in ASP.NET Core Web API

Back to: ASP.NET Core Web API Tutorials

SSO Authentication in ASP.NET Core Web API

In this article, I will discuss How to Implement SSO Authentication in ASP.NET Core Web API step by step with an Example. I have divided the SSO Authentication Implementation into five parts. They are as follows:

• Part 1: Basic Concepts of SSO Authentication will be discussed in this article.
• Part 2: Implementing Authentication Server using ASP.NET Core Web API.
• Part 3: Implementing Resource Server using ASP.NET Core Web API.
• Part 4: Implementing Client Application One using ASP.NET Core MVC.
• Part 5: Implementing Client Application Two using ASP.NET Core MVC.

What is SSO Authentication?

Single Sign-On (SSO) Authentication is a centralized user authentication process that allows a user to log in once using a single set of credentials (for example, a username and password) and gain access to multiple applications or systems without needing to authenticate separately for each one. By centralizing the authentication process on a dedicated server, SSO simplifies the user experience and improves security and administrative efficiency. The following are Key Points for Single Sign-On (SSO) Authentication:

• Centralized Authentication: Users authenticate once with a dedicated Authentication Server.
• Token-Based Access: A secure token (often a JSON Web Token or JWT) is issued upon successful authentication. This token contains user claims (such as user ID, roles, and email) and is used to access various services.
• Enhanced Security and Management: With a single point of authentication, it becomes easier to manage multi-factor authentication (MFA), password policies, and account revocations.

How Does SSO Authentication Work?

Let’s break down a typical SSO flow in an ASP.NET Core Web API environment using JWT (JSON Web Tokens) for secure communication. The process involves multiple components:

• Authentication Server: Responsible for verifying user credentials and issuing tokens.
• Client Applications: These are the different applications that the user accesses.
• Resource Server: Hosts the protected resources that client applications may consume.

Let us understand the Step-by-Step Process of how SSO Authentication Works. For a better understanding, please have a look at the following diagram.

Step 1: Initial Login at Client Application One

The user submits their login credentials (username and password) to Client Application One through a login page. Client Application One then forwards these credentials to the Authentication Server. The Authentication Server validates the credentials, and upon successful validation, it generates a JWT (JSON Web Token) token. This JWT token contains user-specific claims such as User ID, Roles, Email, and other relevant information about the user. So, the following three things happen in Step 1:

• User Action: The user navigates to Application One and submits their credentials through a login form.
• Server Communication: Application One forwards the credentials to the Authentication Server.
• Token Generation: After validating the credentials, the Authentication Server generates a JWT that includes user claims (e.g., User ID, Roles, Email, etc.).

Step 2: Token Delivery and Secure Storage

After validation, the Authentication Server returns the JWT token to Client Application One. This token is stored securely in the user’s browser, typically using Cookies or Session storage. This token is then used to verify the user’s identity for subsequent requests for resources. So, the following two things happen in Step 2:

• Token Delivery: The JWT is sent back to Application One.
• Secure Storage: Application One stores the token securely, typically in cookies or session storage, to persist in the authenticated session and be used for subsequent requests.

Step 3: Initiating SSO for Another Application

When the user attempts to access Client Application Two, they are provided with an SSO link from Client Application One. Clicking on this link sends a request to the authentication server with the previously issued JWT requesting the generation of an SSO token. So, the following two things happen in Step 3:

• User Navigation: When the user chooses to access Application Two, Application One provides an SSO link or button.
• Token Forwarding: Clicking this link initiates a request to the Authentication Server by sending the stored JWT, requesting the generation of a short-lived, unique SSO token (for example, a GUID) that facilitates cross-application access.

Step 4: Generating, Storing, and Returning the SSO Token

Upon receiving the request for an SSO token from Client Application One, the Authentication Server validates the JWT. If valid, it generates a unique SSO token (GUID), stores the token along with user details in the database, and sends the SSO token back to Client Application One. So, the following three things happen in Step 4:

• Validation and Token Generation: The Authentication Server validates the JWT from Application One. If the JWT is valid, it creates a unique SSO token (often a GUID or similarly unique value).
• Persistence: The SSO token, along with the corresponding user information, is stored (e.g., in a database or in-memory store) to track its validity and usage.
• Response: The SSO token is then sent back to Application One.

Step 5: Redirecting the User to Application Two

Once Client Application One receives the SSO token from the Authentication server, it redirects the user to Client Application Two. During the redirection, the SSO token is included either as a query string in the URL or within an HTTP header.

Step 6: Validation of SSO Token at Application Two

Upon receiving the request with the SSO token, Client Application Two sends a request back to the Authentication Server to validate the SSO token. The authentication server checks the SSO token in the database to ensure it is valid and has not expired or been used before.

• If the SSO Token is Valid: The Authentication Server retrieves the stored user details and generates a new JWT access token for Client Application Two. This JWT includes claims such as user ID, Roles, Email, and other relevant information. It is then sent back to Application Two. Upon receiving the JWT, Client Application Two consumes the resource server services.
• If the SSO Token is Invalid: Application Two does not grant access to the user. Depending on the security protocols and user experience, it could redirect the user to a login page or access denied page.

Note: The SSO token is usually designed for one-time use and has a short expiration to prevent replay attacks and unauthorized access.

SSO Authentication Real-time Examples:

SSO is implemented in many environments to address a range of challenges. The following are some of the real-world scenarios illustrating its benefits:

Corporate Environment:

• Scenario: An employee at a multinational corporation needs to access various internal systems such as HR, Email, Project Management, and Financial Reporting throughout the day.
• Challenge without SSO: The employee must repeatedly log in to each system, increasing the chance of password fatigue and security breaches.
• Benefits of SSO: With SSO, the employee logs in just once, saving time and reducing the risk of weak password practices.

Healthcare Sector:

• Scenario: A doctor uses multiple systems to view patient records, lab results, and appointment schedules.
• Challenge without SSO: Switching between systems would require multiple logins, delaying critical decision-making in patient care.
• Benefits of SSO: A single authentication step allows the doctor rapid access to all necessary systems, thereby streamlining patient management and reducing administrative overhead.

Educational Institutions:

• Scenario: Students and faculty need to access academic records, library resources, and online learning platforms.
• Challenge without SSO: Repeated logins across different platforms can lead to frustration and lost productivity.
• Benefits of SSO: One login session across all platforms reduces time wasted on authentication, enhancing productivity and user satisfaction.

E-Commerce and Customer Portals:

• Scenario: Customers accessing various services such as order tracking, customer support, and personalized promotions on an e-commerce platform.
• Challenge without SSO: Repeated logins may lead to a poor user experience and abandoned shopping sessions.
• Benefits of SSO: A seamless login process keeps customers engaged, thereby improving conversion rates and customer loyalty.

What are the Benefits of SSO Authentication?

Single Sign-On (SSO) Authentication provides several key benefits for both users and organizations:

• Enhanced User Experience: With SSO, users log in just once to gain access to multiple applications or systems, reducing the need to remember multiple sets of credentials. With fewer credentials to remember, users experience less password fatigue and fewer login errors.
• Improved Security: SSO centralizes authentication, making it easier to enforce strong security policies, such as multi-factor authentication (MFA) or stricter password requirements. Users are less likely to reuse weak passwords across multiple services, which helps reduce vulnerabilities.
• Increased Productivity: By eliminating repeated logins, SSO allows users to move quickly between applications. This is especially beneficial in environments where individuals regularly access several different systems. Immediate access to multiple systems means less downtime and a more efficient workflow.
• Reduced IT Support Costs: With fewer login credentials to remember, users are less likely to forget their passwords. This reduces the volume of password reset requests to IT support teams, resulting in lower operational costs and freeing up IT resources for more critical projects.
• Minimized Password Fatigue: Users typically struggle to manage multiple passwords for various applications. SSO reduces this burden by allowing users to maintain a single set of credentials. This encourages better password practices and supports stronger, more secure authentication processes.

SSO Implementation with JWT Authentication in ASP.NET Core:

A typical SSO implementation with JWT involves four key components. They are as follows:

• Authentication Server: This central server handles user authentication and issues both JWTs and SSO tokens. This server maintains a secure user store and token validation logic.
• Resource Server: This server hosts the services and data client applications need to access. It accepts JWTs as proof of authentication to allow or deny access.
• Application One (Initial Client): The application where the user logs in initially. Interacts with the Authentication Server to obtain a JWT and, later, an SSO token for redirection.
• Application Two (Secondary Client): A separate application that the user wants to access. Validates the SSO token with the Authentication Server and obtains its own JWT for resource access.

Implementing SSO using JWT in an ASP.NET Core Web API environment simplifies end users’ authentication process and enables centralized management of security policies. By reducing the need for multiple logins, SSO helps lower the risk of weak password practices, minimizes IT support costs related to password resets, and ultimately enhances productivity across various real-world scenarios.

In the next article, we will discuss implementing the Authentication Server using ASP.NET Core Web API. In this article, I explain the basic concepts of SSO Authentication, and I hope you enjoy it.