Two uses that SAML enables

• Single Sign-On (SSO)
  With a single authentication, you can continue using multiple services without having to log in again. For example, once you log in to Okta, you can use Slack and Salesforce without having to log in again.
• Federated Identity / ID Linking
  This system allows IDs to be shared across companies based on "trust." Users managed and authenticated by another organization can be seamlessly accepted into your own organization's services.

There are three characters.

SAML communication involves the following three parties:

• IdP — Identity Provider
  This is the party that verifies the identity of a person, guarantees that "this person is genuine," and issues a certificate (assertion). Examples: Okta, Microsoft Entra ID.
• SP — Service Provider
  This is the service provider's perspective. Users don't perform identity verification themselves; they trust the IdP's (Identity Provider) guarantees and grant access. Examples: Slack, Salesforce.
• User (Browser)
  This is the user. The SP and IdP do not communicate directly; they always communicate through this user's browser.

SAML assertion (proof issued by the IdP)

Once the Identity Provider (IdP) has completed identity verification, it issues a certificate stating, "This person is indeed genuine and is this kind of person." This is a SAML assertion. The Service Provider (SP) verifies this assertion and grants the user access. To prevent tampering, the assertion is digitally signed by the IdP.

Image of characters and their relationship of trust

The relationship between the three parties up to this point can be summarized in the following diagram. The SP and IdP have already established a trust relationship (exchange of certificates and metadata), and the user's browser carries the assertion during the actual login. Terminology (AuthnRequest, ACS URL, etc.) will be explained as it appears in the flow in the next chapter.

Figure: SAML Participants and Trust Relationships

① SP-initiated

This pattern begins with the user attempting to open the app, and it accounts for the majority of SSO implementations in businesses. For example, if you open Salesforce from a browser bookmark, you are redirected to the Okta login screen, authenticated, and then returned to Salesforce.

Figure: SP-initiated sign-in flow

The numbers in the figures correspond to the numbers in the text (① to ⑧).

• Access the app
  The user opens a protected page. The app (SP) determines that the user is "not yet logged in."
• Redirect to IdP (with AuthnRequest)
  The app creates an AuthnRequest (verification request) and instructs the browser to forward to Okta (IdP).
• Redirected to the IdP sign-in page
  Your browser will redirect to the Okta (IdP) SSO URL, and the login screen will be displayed.
• User authentication (ID + PW / MFA)
  Users enter their ID and password in Okta and perform MFA (multi-factor authentication).
• SAML Assertion (Signed XML)
  If identity verification is successful, Okta creates an assertion, signs it, and returns it to the browser.
• POST the assertion to the ACS URL.
  The browser sends the assertion to the app's ACS URL (the URL where assertions are received). The app does not receive it directly.
• Signature verification, user information retrieval, session establishment.
  The application verifies the signature using the IdP's public key (X.509 certificate), confirms the recipient and expiration date, and then creates a session.
• Accessing the app to grant permission (transition to RelayState)
  This completes the login process. You will now be redirected to the "original page you wanted to open" as recorded in RelayState.

② IdP-initiated

This pattern begins with the user opening the Okta dashboard first and then clicking on the app icon listed there. The numbers (① to ⑤) in the diagram and text correspond to this pattern as well.

Figure: IdP-initiated sign-in flow

• Click the app on the IdP dashboard.
  The user selects the icon of the app they want to use from the Okta dashboard.
• Instantly generate SAML assertions
  Okta creates assertions on the spot without waiting for an AuthnRequest (request for verification).
• Return the assertion to the browser.
  Okta passes the signed assertion to the browser.
• POST to ACS URL
  The browser sends the assertion to the app's ACS URL.
• Verification and session establishment → Proceed to landing page
  The app validates the assertion, creates a session, and displays a default page (landing page).

Okta can be both an IdP and a SP.

Up to this point, we've described Okta as an "IdP" (Independent Provider), but Okta can function as both an IdP and a Service Provider (SP) depending on the situation.

• If Okta is the Identity Provider (IdP): Okta manages the IDs and provides SSO to the Service Provider (SP). This corresponds to the "IdP = Okta" configuration in the flow described above.
• If Okta is the Service Provider (SP): When a company already has another Identity Provider (IdP), Okta itself trusts the authentication of the external IdP. Users authenticated by the external IdP are accepted into Okta using JIT provisioning (a mechanism that automatically creates Okta users upon initial sign-in).

→ Okta documentation: SAML app integration

Basic settings (required)

Figure: SAML settings (basic settings)

Advanced settings

Opening "Show advanced settings" will reveal important security-related items. The main ones are as follows:

Figure: SAML settings (advanced settings)

Attribute statement

User attribute and group information passed to the SP is defined in the "attribute statement".

However, attribute statements cannot be set during the App Integration Wizard (AIW). As shown in the diagram below, they are added and edited from the "Sign On" tab after app creation (Okta Expression Language is used to specify values).

→ Okta documentation: Configuring custom claims for app integrations

Figure: Attribute statement settings

Things to decide before implementation

• Check whether your company uses OIE or Classic Engine.
  Okta's management interface and configuration options differ between the Identity Engine (OIE) and the Classic Engine. Please refer to the documentation appropriate for your environment (for OIE or Classic) for instructions.
• Secure an emergency access method (backdoor).
  If Okta, our Identity Provider (IdP), experiences an outage, administrators may be unable to access the application. Therefore, we will prepare emergency alternatives, such as local authentication other than SAML.

"SAML Response" and "Assertion" are different things.

They are often confused, but the relationship between the two is like "envelope and its contents." The SP's ACS URL receives the outer Response, and the assertion is extracted from within that and verified.

Figure: Nested structure of SAML Response and Assertion

[SAML 2.0 consists of four components]

The SAML specification consists of four layers with different roles. It is a structure that builds from foundational assertions to specific use cases (profiles).

Figure: SAML 2.0 4-layer structure

Assertion-related elements that can be configured and checked in Okta

The following are items that can be configured and output controlled by Okta's AIW and features (general elements of the SAML specification are omitted).

Single Logout (SLO): Single Logout

This feature allows users to terminate both their Okta session and their SP session in a single action when they press the SP logout button. This prevents situations where "the user logs out of the app, but Okta remains active."

[Okta's support status and limitations]

Okta's SLO only supports SP-initiated triggers. The Okta session ends when the SP sends a signed SLO request to Okta.

Furthermore, the Identity Engine (OIE) has a "Front-channel SLO (Multiple Device SLO)" feature, where Okta, upon receiving an SLO request initiated by the Service Provider (SP), sends a chain reaction of sign-out requests to other participating applications (a two-tiered structure: the initial trigger is initiated by the SP, and the notification from Okta to other applications is initiated by the Identity Provider (IdP)).

Furthermore, only some apps support SLOs. SWA apps do not support them, and SAML apps only support them if the SP can send signed SLO requests (please check the guide for each app to see if it supports them).

→ Okta documentation: Configuring single logout in app integration

→ Okta documentation: Configure Single Logout

Handling incompatible apps based on the IdP (Okta's proprietary method)

Even apps that only support SP-initiated flows can simulate IdP-initiated flows using Okta's Bookmark App integration (an icon is displayed on the dashboard and launched from there).

→ Okta documentation: Simulate IdP-initiated flows with the Bookmark app

Combination with MFA

Okta allows you to require MFA (Multi-Factor Authentication) before issuing an assertion. The assertion will include a statement indicating whether MFA has been used, and the Service Provider (SP) can verify this. It is also possible to explicitly pass the authentication method using the aforementioned session.amr attribute.

→ Okta documentation: SAML app integration

SAML vs. Other Protocols Comparison

Detailed comparison table

Both SAML and OIDC enable identity federation, but their design philosophies are fundamentally different. The main differences are summarized in the table below.

Comparison of JWT and SAML Assertion

Both OIDC ID tokens (JWT) and SAML assertions (XML) are "signed tokens that prove the user's identity," but their formats differ significantly. The main differences are as follows:

A major advantage of JWTs is their compact size, which allows them to be directly attached to the Authorization header of mobile apps and APIs.

Which should you choose: Selection framework

[Okta's official statement]

Okta recommends OIDC for new SSO integrations. OIDC is also recommended for apps newly registered with OIN (Okta Integration Network). SAML is positioned as an option to use for integration with existing systems or when there are specific requirements.

→ Source (Okta documentation): Overview of Single Sign-On in the OIN / Create an app integration

The option of coexistence

SAML and OIDC are not mutually exclusive. In practice, large corporations often use them interchangeably depending on the purpose.

• Legacy apps → SAML, New apps → OIDC
  Okta supports both as an IdP. You can maintain existing SAML integrations while adopting OIDC for new apps.
• Okta absorbs protocol differences.
  By using Okta as a hub, it's possible to configure the application to communicate solely via OIDC, while Okta handles communication with external SAML IdPs in the background.

[OIDC is not a "backward compatible" version of SAML.]

While OIDC is modern and easy to use, SAML has an advantage in areas where it excels (enterprise identity federation, attribute-based access control, and mature SLOs). It's not a case of "OIDC is better because it's newer," but rather a choice based on the use case.