Osano supports SP-initiated SSO only across both SAML 2.0 and OIDC.

For SAML, Osano supports standard SP-initiated SAML 2.0 flows with a persistent NameID, but do not support IdP-initiated logins.

For OIDC, Osano supports the Authorization Code Flow only, requiring a stable sub identifier, and do not support implicit, hybrid, or IdP-initiated flows.

Osano SSO (SAML 2.0) Support Guide

Osano supports Single Sign-On (SSO) using SAML 2.0 via Amazon Cognito. This document outlines what we support, what we don’t support, and what is required from your Identity Provider (IdP) to successfully configure SSO.

What Osano Supports

✅ SAML 2.0 (SP-Initiated SSO Only)

Osano supports Service Provider (SP)-initiated SSO, where:

1. The user starts at Osano (or an Osano login page)

2. Osano redirects the user to your Identity Provider (IdP)

3. The IdP authenticates the user

4. The IdP sends a SAML response back to Osano (via Amazon Cognito)

5. The user is logged into Osano

This is the only supported authentication flow.

Standard SAML POST Binding (Assertion Delivery)

• Your IdP must send SAML assertions via HTTP POST to the Osano SSO endpoint

• Osano (via Amazon Cognito) directly processes the SAML assertion

ACS (Assertion Consumer Service) URL:

https://<your-domain>/saml2/idpresponse

✅ Required SAML Assertion Elements

Your IdP must provide:

• NameID (persistent identifier)

  • Must be stable and not change over time

• AudienceRestriction

  • Must match the Osano/Cognito SP Entity ID

• Required attributes (e.g., email)

  • Must be mapped correctly in your IdP
    

✅ Secure, Signed Assertions

• IdP must provide a valid signing certificate

• Assertions must be signed

• Optional: encrypted assertions (if configured)
  

What Osano Does NOT Support

To ensure security and consistency, Osano intentionally does not support the following:

❌ IdP-Initiated SSO

• Users cannot start login from the IdP dashboard (e.g., Okta tile, Azure portal)

• Osano must initiate the authentication flow

Why:

• Prevents unsolicited SAML responses

• Reduces risk of spoofing and CSRF attacks

• Ensures proper session validation
  

❌ POST Binding Variants Outside Standard Flow

• Only standard SP-initiated POST binding to /saml2/idpresponse is supported

• Custom or non-standard bindings are not supported
  

❌ SAML Assertion Replay

• Reusing or replaying SAML assertions will fail authentication
  

❌ Dynamic or Changing User Identifiers

• If your NameID changes, Osano will treat the user as a new account

• Persistent identifiers are required
  

❌ Non-Standard Attribute Encoding

• Unsupported characters (e.g., certain 4-byte UTF-8 characters) must be encoded

• Failure to do so may cause authentication errors
  

What You Need to Provide

To configure SSO with Osano, your team will need to provide:

1. IdP Metadata

One of the following:

• Metadata URL (must use HTTPS on port 443), or

• Metadata XML file
  

2. Signing Certificate

• Must be valid and not expired

• Multiple certificates supported (for rotation)
  

3. Attribute Mapping

At minimum:

• Email (required)

• NameID (persistent unique identifier)
  

4. IdP Configuration

Your IdP must be configured to:

• Support SAML 2.0

• Use SP-initiated login only

• Send assertions via HTTP POST

• Target the correct ACS URL

• Include required claims
  

Osano SSO (OIDC) Support Guide

Osano supports Single Sign-On (SSO) using OpenID Connect (OIDC) via Amazon Cognito. This document outlines what we support, what we don’t support, and what is required to configure OIDC SSO.

What Osano Supports

✅ OpenID Connect (OIDC) – Authorization Code Flow

Osano supports OIDC using the Authorization Code Flow.

Flow:

1. User starts authentication from Osano

2. Osano redirects the user to your Identity Provider (IdP)

3. The IdP authenticates the user

4. The IdP redirects back to Osano with an authorization code

5. Osano exchanges the code for tokens (ID + Access)

6. User is logged in

This is the only supported OIDC flow.

✅ SP-Initiated Authentication Only

• Authentication must start from Osano

• Osano controls the session and request lifecycle
  

✅ Token-Based Authentication

Your IdP will return:

• ID Token (JWT) → used for authentication

• Access Token (JWT) → used for authorization (if applicable)

Osano validates and processes these tokens automatically.

✅ Standard OIDC Claims

Your IdP must provide:

• sub (subject) → unique, stable user identifier

• email → required for user mapping

• Optional: name, given_name, family_name
  

✅ Secure Token Exchange

• Tokens must be signed using your IdP’s keys

• Osano validates tokens using your JWKS endpoint
  

What Osano Does NOT Support

❌ Implicit Flow

• Osano does not support implicit flow (response_type=token)

• Only Authorization Code Flow is supported
  

❌ IdP-Initiated / Direct Login

• Users cannot initiate login directly from the IdP

• (e.g., launching from Okta dashboard without redirect from Osano)

All authentication must begin from Osano.

❌ Hybrid or Non-Standard Flows

• No support for hybrid flows (code + token)

• No custom token exchange mechanisms
  

❌ Changing User Identifiers

• If the sub claim changes, the user will be treated as a new account

• Must be persistent and stable
  

What You Need to Provide

To configure OIDC SSO with Osano:

1. OIDC Configuration Details

• Issuer URL

• Authorization Endpoint

• Token Endpoint

• JWKS URI
  

2. Client Credentials

• Client ID

• Client Secret (if applicable)
  

3. Redirect URI (from Osano)

Osano will provide a redirect URI such as:

https://<your-domain>/oauth2/idpresponse

This must be allowlisted in your IdP.

4. Required Scopes

At minimum:

openid email

5. Claim Mapping

Ensure:

• sub → unique user identifier

• email → required for user account mapping