Single Sign-On (SSO)

paul chou
8 min readSep 20, 2024

--

SSO, or Single Sign-On, is an authentication method that allows users to access multiple applications or services with a single set of login credentials. It simplifies the user experience by reducing the number of passwords users need to remember and manage.

When a website offers you the option to “Log in with Google” (or another provider like Facebook), it’s using Single Sign-On (SSO).

Four major OAuth 2.0 flows (or “grant types”) commonly used in Single Sign-On (SSO) scenarios. Each flow is designed for different use cases and security requirements. Here’s a breakdown:

1. Authorization Code Flow

  • Best for: Server-side applications where the client can keep secrets securely.
  • How it works:
  • The user is redirected to the authorization server to log in.
  • The server returns an authorization code to the client app’s redirect URI.
  • The client exchanges this code for access and ID tokens.
  • Why it’s secure: The exchange happens server-to-server, keeping tokens and secrets safe from exposure in the browser.
  • Example: Logging into a web app using Google, and the app exchanges an authorization code for a token.

2. Implicit Flow

  • Best for: Public client applications (e.g., JavaScript SPAs) that cannot store secrets securely.
  • How it works:
  • The user is redirected to the authorization server, which directly returns the access token (and sometimes an ID token) without an authorization code.
  • Why it’s less secure: Tokens are exposed in the browser, making it more vulnerable to attacks (such as token hijacking).
  • Example: Single-page apps (SPAs) that need immediate access to an access token after login.

3. Resource Owner Password Credentials Flow (ROPC)

  • Best for: Trusted applications (typically internal applications).
  • How it works:
  • The user provides their username and password directly to the client application.
  • The client uses these credentials to request an access token from the authorization server.
  • Why it’s less secure: Since the client directly handles the user’s credentials, there is a higher risk of credential compromise.
  • Example: Legacy systems or internal applications where the user’s credentials are already stored.

4. Client Credentials Flow

  • Best for: Server-to-server communication, where no user interaction is needed.
  • How it works:
  • The client (usually a backend service) directly requests an access token from the authorization server using its client ID and secret.
  • Why it’s secure: There’s no user involved, and the client can keep its secret securely.
  • Example: A microservice authenticating with another microservice.

Each of these flows has its specific use cases and security considerations, depending on the type of application and the sensitivity of the data being accessed.

What is keycloak?

Keycloak, developed by Red Hat, is a powerful access management solution designed to handle user authentication, authorization, and single sign-on (SSO) for modern applications and services. It’s especially beneficial for organizations aiming to implement comprehensive security across their software ecosystem with ease.

To begin, we will install Keycloak using Docker. The choice of Docker simplifies the setup process by providing a standardized environment that encapsulates all necessary dependencies. This approach not only makes installation more efficient but also serves as an ideal setup for demonstration purposes.

Click the following link and follow the instructions to start a Keycloak container: Keycloak Docker Getting Started

Keycloak admin interface

After successfully starting and logging into Keycloak, you should see the Keycloak admin interface, which includes:

  • A main navigation bar on the left, providing access to user management, group management, client settings, authentication, and other functionalities.
  • The center of the interface will display the current realm configuration, where you can add, edit, or delete different realms.
  • On the top right, there are quick access buttons for system settings and other related actions.

Once Keycloak is up and running, the first step is to configure a realm. A realm in Keycloak represents a security boundary, where each realm is completely isolated from the others. Every realm has its own user database, authentication configurations, and authorization policies. This architecture allows Keycloak to offer tailored security solutions for different applications, even when they are managed within the same Keycloak instance, ensuring each application’s security is independently maintained.

realm interface

The following setup is to set up a user, it represents an individual who interacts with the system or applications secured by Keycloak. Each user in Keycloak can have associated credentials (like usernames, passwords, or social login tokens) and attributes (like email addresses, roles, or other metadata). Users can be part of a realm and have specific roles or permissions within that realm.

user interface
dont forget to set up password

After creating a user in Keycloak, you can use that account to log in. The URL format for accessing the login page is:

http://localhost:8080/realms/{realm-name}/account
  • localhost:8080 is the default address where Keycloak runs.

Next, you can create clients in Keycloak. A client in Keycloak represents an application or service that Keycloak secures.Clients are essentially entities that request authentication from Keycloak on behalf of users, like a web app, mobile app, or API.

client interface

In the Keycloak client interface, you’ll see two main client types: OpenID Connect (OIDC) and SAML. Here’s a simple explanation of each:

  1. OpenID Connect (OIDC):
  • OIDC is an authentication protocol built on top of OAuth 2.0, used primarily for modern web applications.
  • It allows users to authenticate (log in) to your app through Keycloak and also get identity information (like user profile details).
  • Example: Logging into a website using your Google account.
  1. SAML (Security Assertion Markup Language):
  • SAML is an older but still widely used protocol for exchanging authentication and authorization data between parties, especially in enterprise settings.
  • It works by allowing users to log in once and then access multiple services without needing to log in again (Single Sign-On or SSO).
  • Example: A company employee logging into different internal systems without entering credentials multiple times.

These client types define how Keycloak communicates with the application to handle user authentication and identity management

  • Client Authentication: This ensures that the client (the application or service) needs to authenticate itself with Keycloak, often requiring a password or other credentials to prove its identity.
  • Authorization: This controls what users can do within the client (the application or service), managing their permissions and access rights after they have logged in.

If the Client authentication toggle is on, then there is a credentials tab on the top. Click into the credentials, client password is showed in the cloumn

And this is the brief intro of how to set up keycloak.

Hang in there, everyone — I’m almost finished! Now, I’ll demonstrate how to use Postman to complete the entire authorization code flow.

First, navigate to the Keycloak admin page. Click on “Realms” in the main navigation bar, then select your realm. Look for the “Endpoints” link, which will show all the necessary endpoints for the authentication process.

Copy the authorization_endpoint URL and paste it into Postman. This URL is essential for initiating the authorization code flow, and Postman will help you test and manage the process from there.

OpenID Endpoint Configuration

Here’s a brief description of each parameter you need to fill in for the Keycloak client:

  • client_id: The unique identifier for your client (application) in Keycloak.
  • response_type: Specifies the type of response you want from Keycloak, such as code for the authorization code flow.
  • scope: Defines the access level or permissions requested, often including openid for basic authentication.
  • redirect_uri: The URL to which Keycloak will send the user after authentication, where your app will handle the response.
  • state: A unique string used to maintain state between the request and the callback, helping prevent CSRF attacks.

Next, copy the entire URL with the parameters you’ve set (including client_id, response_type, scope, redirect_uri, and state) and paste it into your browser or Google Chrome.

This will direct you to the Keycloak login page. Once you log in, Keycloak will handle the authorization process according to the parameters you specified.

After logging in, if you encounter a “site can’t be reached” error but notice that the URL has changed, copy this new URL and paste it into Postman. This new URL often contains important information such as an authorization code or token, which you’ll need to complete the authorization process. The URL looks like this

http://localhost:8083/callback?state=1234&session_state=bf0b0d9d-6fa6-4b78-8cf5-2d7eb6bbfae3&iss=http%3A%2F%2Flocalhost%3A8080%2Frealms%2Ftest&code=c1d1ff65-64e3-4cfb-ad07-08c7083eaed7.bf0b0d9d-6fa6-4b78-8cf5-2d7eb6bbfae3.173d4c60-db5c-4336-976c-533bbea5521d

After pasting the changed URL into Postman, extract the authorization code from the URL. Look for the part of the URL that begins with code= and copy the value that follows it. This authorization code is needed to complete the OAuth 2.0 flow and exchange it for an access token.

Here’s a brief explanation of each parameter:

  • grant_type: authorization_code: This specifies the OAuth 2.0 authorization flow being used, which is the “Authorization Code” flow.
  • client_id: client-auth-code: The unique identifier for the client application that’s requesting access.
  • client_secret: A secret key assigned to the client application.
  • code: The authorization code issued by the authorization server after the user successfully logs in and grants permission. The app will exchange this code for an access token.
  • redirect_uri: The URL to which the authorization server redirects the user after they’ve logged in and granted permissions.
  • scope: These are the requested scopes, defining what level of access the client application is asking for.

Once the app receives the authorization code at the redirect_uri, it can exchange this code for two tokens:

  1. access_token: This token is used to grant the client application access to the user’s resources (like their profile data, for example). It allows the app to make authorized API calls on behalf of the user.
  2. id_token: This token contains information about the authenticated user (such as their user ID, email, etc.). It’s typically used for identity verification and is based on the OpenID Connect (OIDC) protocol.

After validation, the authorization server will return the access_token and id_token, allowing the app to securely authenticate and interact with the user's data.

--

--

No responses yet