Introduction to Password-Based Single Sign-On (SSO) Implementation

Explore the benefits and process of password-based SSO, enhancing user experience and security while simplifying management across applications. Learn how SSO works, its implementation steps, and the importance of trust in client handling of user credentials.

What is SSO?

SSO (Single Sign-On) is an authentication and authorization mechanism that allows users to log in to an Identity Provider (IdP) with a set of credentials, such as a username and password, and then access multiple associated applications or systems without re-entering their credentials. Traditional authentication requires users to provide separate credentials for each application or system, which can be cumbersome and requires managing multiple credentials when switching between applications. The goal of SSO is to address this issue by introducing a central identity provider, allowing users to authenticate once and then seamlessly access other associated applications.

In SSO, the identity provider is typically a separate authentication server or service responsible for verifying the user's identity. Once the user is authenticated, the identity provider issues a token (called a token ticket) to the user. This token can be used by the user to prove their authenticated status when accessing other associated applications. Other applications rely on the identity provider to verify the validity of the token and authorize the user to access the corresponding resources or functions.

Advantages of SSO

The advantages of SSO include:

  • User-Friendly: Users can access multiple applications with a single login, providing a better user experience.
  • Enhanced Security: As users only need to enter their credentials once, the risk of password leakage or forgetting is reduced.
  • Simplified Management: Administrators can more easily manage user credentials and access permissions, reducing repetitive work.
  • Reduced Development Costs: Applications can rely on the identity provider to handle authentication and authorization logic, reducing the complexity and development workload of the application itself.

Password-Based SSO Implementation

The password mode referred to here is the password mode of Auth2.0 (for a complete reading of OAuth2.0, please refer to Understanding OAuth2.0). Compared to the authorization code mode, the password mode is much simpler. In the password mode, users provide their username and password to the client. The client uses this information to request authorization from the identity provider.

Login Process

  1. Username/Password: The user sends a login request to the client, carrying username/password information. Note that the password should be encrypted to avoid plaintext transmission.
  2. Client: The client passes the username/password to the identity provider service, which verifies the correctness of the password.
  3. Identity Provider: The identity provider generates an access_token and returns it to the client.
  4. Client: The client returns the access_token to the user.

Authentication Process

  1. Request with access_token: The user client requests the validation of the access_token.
  2. access_token Validation: Validate the validity of the access_token.
  3. Validation Result: Based on the validation result, decide whether to return the result.

Business Request

  1. User Client: The user client initiates a business request, carrying the access_token via parameters or the Authorization method, with the Authorization method recommended.
  2. Client: The client passes the access_token to the identity provider for validity verification.
  3. Identity Provider: The identity provider verifies the validity of the access_token.
  4. Identity Provider: The identity provider returns the validation result to the client.
  5. Client: The client decides whether to return the business request result or a Forbidden error based on the validation result.

If a Forbidden Error is Received

The user can choose to re-initiate the login process.

This is the login and authentication process based on the password mode. When multiple clients connect to the same identity provider, SSO is achieved.

Refresh Process

In fact, the identity provider can also provide a refresh_token renewal process for the access_token: when returning the access_token after login, a refresh_token can also be returned, allowing the user to request the renewal of the access_token with the refresh_token as needed.

Limitations of Password Mode

In the password mode, users must give their password to the client, but the client must not store the password. This is usually used in situations where users highly trust the client, such as when the client is part of an enterprise product. If the client is not highly trustworthy, do not use this mode of implementation; it is recommended to use the authorization code mode.