SAML SSO Authentication Flow Explained

SSO Authentication Flow

This document outlines the typical Service Provider (SP) initiated SAML Single Sign-On (SSO) authentication flow, using Gmail as the Service Provider and Okta as the Identity Provider.

Key Components:

• User: The individual attempting to access a service.

• Service Provider (SP): The application or service the user wants to access (e.g., Gmail).

• Identity Provider (IdP): The system that authenticates the user and provides identity assertions (e.g., Okta).

• Browser: The user’s web browser, which facilitates communication between the SP and IdP.

The Authentication Flow Steps:

1. User Initiates Access:

   • The User attempts to access a protected resource or logs into the Service Provider (Gmail) directly.

2. Service Provider Initiates SAML Request:

   • The Service Provider (Gmail) recognizes that the user needs to be authenticated by an external Identity Provider.

   • It generates a SAML AuthnRequest (Authentication Request). This request contains information about the SP and the requested authentication context.

   • The SP then redirects the user’s Browser to the Identity Provider’s (Okta) SSO endpoint, including the SAML AuthnRequest (often URL-encoded in a query parameter or sent via a POST request).

3. Browser Redirects to Identity Provider:

   • The user’s Browser receives the redirect from the SP and navigates to the Identity Provider (Okta). The SAML AuthnRequest is passed along.

4. User Authentication at Identity Provider:

   • The Identity Provider (Okta) receives the SAML AuthnRequest.

   • It checks if the User is already logged in (has an active session).

   • If the user is not logged in: The IdP prompts the user to log in (e.g., with username and password, multi-factor authentication).

   • If the user is already logged in: The IdP proceeds without requiring re-authentication.

5. Identity Provider Generates SAML Response:

   • Upon successful authentication (or if an active session exists), the Identity Provider (Okta) generates a SAML Response.

   • This response contains a digitally signed SAML Assertion, which confirms the user’s identity and attributes (e.g., username, email, group memberships) to the Service Provider.

   • The IdP then redirects the user’s Browser back to the Service Provider’s (Gmail) Assertion Consumer Service (ACS) endpoint, including the SAML Response (typically via a POST request).

6. Browser Redirects Back to Service Provider:

   • The user’s Browser receives the redirect from the IdP and navigates back to the Service Provider (Gmail), carrying the SAML Response.

7. Service Provider Validates SAML Response:

   • The Service Provider (Gmail) receives the SAML Response.

   • It validates the digital signature of the SAML Assertion using the IdP’s public key.

   • It also checks other aspects of the assertion, such as its validity period, audience restrictions, and the user’s attributes.

8. User is Logged In:

   • If the SAML Response and Assertion are valid, the Service Provider (Gmail) successfully authenticates the User.

   • The user is then granted access to the requested resource or logged into the Gmail application.

   • User is logged in ✅

This flow ensures that the Service Provider trusts the Identity Provider to authenticate the user, without the SP ever needing to store or manage the user’s credentials directly.