Creating an SSO Session

Kigo supports Single Sign-On (SSO) so your members can move from your website or app into a Kigo-powered experience without a separate Kigo login. Every SSO method ends the same way: Kigo issues a short-lived SSO session ID for the member, and the Kigo-hosted experience exchanges that ID for a signed-in session.

Kigo supports three SSO methods. You only need one. Pick the one that fits your existing infrastructure.

SSO Methods at a Glance

• Partner API Key integration guide
• SAML 2.0 integration guide
• OpenID Connect (OIDC) integration guide

Before You Start

Whichever method you choose, work with your Kigo account manager to:

1. Set up your program. Kigo creates (or confirms) your program and its external_program_id, the identifier that tells Kigo which branded experience a member belongs to.
2. Enable SSO for the program. SSO must be turned on for each program before any method will work. The Partner API Key method also requires the API-key method to be enabled.
3. Agree on a test plan. Every integration is set up and tested in Kigo's test environment before production.

How the Session ID Is Used

The SSO session ID is what signs the member in. It is:

• Short-lived: valid for 30 minutes after it is created.
• Single-use for SAML and OIDC. For the Partner API Key method, you choose with the is_single_use flag (single-use is recommended).
• Safe to send to the browser: it grants one member access to one program for a limited time. Your partner credentials, IdP secrets, and signing keys must never reach the browser.

The member is signed in when their browser opens the Kigo-hosted experience with the session ID in the URL. The general shape of that URL is:

{base_url}/sso/{external_program_id}?uuid={session_id}

📘

Base URL and path

The base URL and path depend on which Kigo-hosted experience your program uses. Once you can create a session ID, contact your Kigo account manager for the base URL and path for your program in each environment (test and production).

• Partner API Key: your application builds this URL with the session_id it received and redirects the member (or loads it in an iframe).
• SAML 2.0 and OIDC: you do not build the URL. Kigo redirects the member to the redirect URL configured for your integration, with ?sessionId={session_id} appended. Kigo sets up that redirect URL with you during onboarding.

Accounts

You do not need to create Kigo accounts ahead of time. The first time a member signs in through any SSO method, Kigo creates their account in your program, keyed on your identifier for them (external_user_id, SAML NameID, or OIDC sub). Later sign-ins with the same identifier reach the same account. Use an identifier that never changes for the member, such as an internal member ID, rather than an email address that may change.

Security Summary

• All traffic to Kigo is HTTPS only.
• Partner API keys and partner-level tokens stay on your servers.
• SAML assertions must be signed by your IdP. Kigo validates the signature against the IdP metadata you provide.
• OIDC uses the Authorization Code flow with PKCE (S256), state, and nonce. Kigo verifies every ID token signature against your IdP's published keys.
• Session IDs expire after 30 minutes.