SAML & OIDC Applications

Learn how to configure Single Sign-On (SSO) applications using SAML 2.0 and OpenID Connect (OIDC) protocols. This guide covers application setup, protocol configuration, and SSO implementation.

Table of Contents

1. SSO Overview

Single Sign-On (SSO) allows users to authenticate once and gain access to multiple applications without entering credentials again. OKTA acts as the Identity Provider (IdP) that authenticates users and provides access to Service Provider (SP) applications.

Benefits of SSO:

  • Improved user experience: Users log in once and access all applications
  • Enhanced security: Centralized authentication and access control
  • Reduced password fatigue: Users don't need to remember multiple passwords
  • Centralized management: Admins manage access from one place
  • Compliance: Easier to meet security and audit requirements

1.1 SSO Flow

Typical SSO flow:

  1. User attempts to access an application
  2. Application redirects user to OKTA for authentication
  3. User authenticates with OKTA (username, password, MFA)
  4. OKTA creates a security token (SAML assertion or OIDC token)
  5. OKTA redirects user back to application with token
  6. Application validates token and grants access

2. SAML 2.0 Protocol

SAML (Security Assertion Markup Language) 2.0 is an XML-based protocol for exchanging authentication and authorization data between identity providers and service providers. It's widely used for enterprise SSO.

2.1 SAML Components

Key SAML components:

  • Identity Provider (IdP): OKTA, which authenticates users
  • Service Provider (SP): The application users want to access
  • SAML Assertion: XML document containing authentication and attribute information
  • SAML Request: SP-initiated request for authentication
  • SAML Response: IdP's response containing assertion

2.2 SAML Bindings

SAML supports different bindings for message transport:

  • HTTP Redirect: SAML messages sent as URL parameters
  • HTTP POST: SAML messages sent in form data
  • HTTP Artifact: Reference to assertion instead of full assertion
  • SAML SOAP: SOAP-based binding (less common)

2.3 SAML Assertion

A SAML assertion contains:

  • Authentication statement: Confirms user was authenticated
  • Attribute statement: User attributes (email, name, groups)
  • Authorization statement: Permissions and access rights
  • Subject: User identifier
  • Conditions: Validity period and audience restrictions

3. SAML Configuration

To configure a SAML application in OKTA:

3.1 Create SAML Application

  1. Navigate to Applications → Applications
  2. Click Create App Integration
  3. Select SAML 2.0 as the sign-in method
  4. Enter application name and logo (optional)
  5. Click Next

3.2 Configure SAML Settings

Configure SAML settings:

  • Single Sign-On URL: Application's SAML endpoint (ACS URL)
  • Audience URI (SP Entity ID): Application's entity identifier
  • Name ID format: How user identifier is sent (email, username, etc.)
  • Response: Signed or unsigned
  • Assertion Signature: Sign assertion with certificate
  • Signature Algorithm: RSA-SHA256 or RSA-SHA1
  • Digest Algorithm: SHA256 or SHA1
  • Attribute Statements: Map OKTA attributes to SAML attributes

3.3 SAML Attributes

Configure attribute statements to send user data to the application:

  • Email: User's email address
  • First Name: User's first name
  • Last Name: User's last name
  • Groups: User's group memberships
  • Custom attributes: Any custom profile attributes

Example attribute mapping: 

Name: Email
Name format: Unspecified
Value: user.email

Name: FirstName
Name format: Unspecified
Value: user.firstName

Name: Groups
Name format: Unspecified
Value: user.groups

3.4 SAML Metadata

OKTA provides SAML metadata containing:

  • Entity ID
  • SSO URL (Single Sign-On Service URL)
  • X.509 certificate for signature verification
  • Supported bindings and name ID formats

Application can import OKTA metadata URL or download metadata XML file.

3.5 Application-Side Configuration

On the application side, configure:

  • OKTA's Entity ID
  • OKTA's SSO URL
  • OKTA's X.509 certificate
  • ACS URL (Assertion Consumer Service URL)
  • Attribute mappings

4. OpenID Connect Protocol

OpenID Connect (OIDC) is a modern authentication protocol built on OAuth 2.0. It provides authentication and user information through JSON Web Tokens (JWTs). OIDC is simpler than SAML and better suited for modern web and mobile applications.

4.1 OIDC vs SAML

Key differences:

  • Protocol: OIDC uses OAuth 2.0 + JWT, SAML uses XML
  • Complexity: OIDC is simpler, SAML is more complex
  • Use cases: OIDC for modern apps/APIs, SAML for enterprise SSO
  • Mobile: OIDC better for mobile apps
  • REST APIs: OIDC preferred for API authentication

4.2 OIDC Components

Key OIDC components:

  • Authorization Server: OKTA, which issues tokens
  • Client: The application requesting authentication
  • Resource Owner: The user
  • ID Token: JWT containing user identity information
  • Access Token: Token for accessing protected resources
  • UserInfo Endpoint: API endpoint to get user information

4.3 OIDC Flow

Authorization Code flow (most common):

  1. User clicks "Sign in" in application
  2. Application redirects to OKTA authorization endpoint
  3. User authenticates with OKTA
  4. OKTA redirects back with authorization code
  5. Application exchanges code for ID token and access token
  6. Application validates ID token and extracts user info
  7. Application grants access to user

5. OIDC Configuration

To configure an OIDC application in OKTA:

5.1 Create OIDC Application

  1. Navigate to Applications → Applications
  2. Click Create App Integration
  3. Select OpenID Connect as the sign-in method
  4. Choose application type:
    • Web Application: Server-side applications
    • Single-Page App: JavaScript/SPA applications
    • Native App: Mobile or desktop applications
    • Service: Machine-to-machine applications
  5. Enter application name
  6. Click Next

5.2 Configure OIDC Settings

Configure OIDC settings:

  • Grant types: Authorization Code, Implicit, Refresh Token, etc.
  • Sign-in redirect URIs: Where OKTA redirects after authentication
  • Sign-out redirect URIs: Where OKTA redirects after sign-out
  • Initiate login URI: Deep link for mobile apps
  • Application username: How username is displayed
  • Group filter: Which groups to include in tokens

5.3 Client Credentials

After creating the application, OKTA provides:

  • Client ID: Public identifier for the application
  • Client Secret: Secret key (for confidential clients)
  • OKTA Domain: Your OKTA organization URL
  • Authorization Server: Default or custom authorization server

5.4 OIDC Scopes

OIDC scopes control what information is included in tokens:

  • openid: Required for OIDC
  • profile: User profile information (name, email)
  • email: User email address
  • address: User address
  • phone: User phone number
  • groups: User group memberships
  • offline_access: Refresh token

5.5 ID Token Claims

ID token contains claims (user information):

  • sub: Subject (user identifier)
  • email: Email address
  • name: Full name
  • given_name: First name
  • family_name: Last name
  • groups: Array of group names
  • preferred_username: Username

6. Application Assignment

After configuring an application, assign it to users or groups so they can access it.

6.1 Assign to Users

  1. Open the application
  2. Go to Assignments tab
  3. Click Assign → Assign to People
  4. Search and select users
  5. Configure user-specific settings (if any)
  6. Click Save and Go Back

6.2 Assign to Groups

  1. Open the application
  2. Go to Assignments tab
  3. Click Assign → Assign to Groups
  4. Search and select groups
  5. Configure group-specific settings
  6. Click Save and Go Back

All members of assigned groups automatically get access to the application.

6.3 Application Access

Once assigned, users can access the application:

  • From OKTA dashboard (OKTA Home)
  • Directly from application URL (if SP-initiated SSO)
  • Via deep links or bookmarks

6.4 Testing SSO

To test SSO configuration:

  1. Assign application to a test user
  2. Log in as test user
  3. Click application icon in OKTA dashboard
  4. Verify successful authentication
  5. Check that user attributes are correctly passed
  6. Test sign-out flow

Summary

SAML 2.0 and OpenID Connect are the two primary protocols for implementing SSO in OKTA. SAML is XML-based and widely used for enterprise SSO, while OIDC is modern, JSON-based, and better suited for web and mobile applications. Both protocols enable users to authenticate once and access multiple applications. Configuration involves setting up the application in OKTA, configuring protocol-specific settings, mapping user attributes, and assigning the application to users or groups. Understanding these protocols and their configuration is essential for implementing effective SSO solutions.

Tags:

Post a Comment

0 Comments