Single Sign-On (SSO)

SSO allows your organization to use your existing Identity Provider (IdP) to authenticate users accessing the Alokai Console. Instead of managing separate usernames and passwords, your team can use their existing corporate credentials to securely access the console.

How SSO Works

Step	Action	Result
1	User enters their email on the Console login page	System checks the domain
2	Domain is configured for SSO	User is redirected to the Identity Provider (IdP)
3	User authenticates with corporate credentials in the IdP	IdP validates identity and issues SAML response
4	SAML response is sent back to Alokai Console	User is logged into the Console without a separate password
5	Access management is handled in the IdP	Adding/removing users in IdP updates their Console access

SSO Authentication Flow

Enabling SSO for Your Organization

Contact Support Reach out to Alokai Support to start the setup.
Technical details (provided by Support)

Entity ID (Issuer): https://console.alokai.com/oauth/sso/issuer/{providerId}
SAML Format: SAML 1.1
Name ID Format: Email address
Name ID: The email field should be mapped as the Name ID attribute

Configure your IdP Add the Alokai Console as an application in your identity provider (such as Okta, Azure AD, or Google Workspace) using the information provided above.
Send back to Alokai
- SSO Login Endpoint URL - The URL where users should be redirected for authentication
- X.509 Certificate - The public certificate used to verify SAML responses
- Email Domains - List of email domains for which SSO should be enabled (e.g., yourcompany.com, subsidiary.com)

Troubleshooting

Existing accounts in your domain

When SSO is enabled, all existing accounts under the configured domain are automatically linked to SSO.
Account data remains unchanged; only the authentication method switches to SSO.

Managing access after enabling SSO

Access is controlled entirely through your Identity Provider (IdP).
Adding or removing a user in the IdP immediately updates their ability to log in to the Console.
Password-based login is disabled for SSO-enabled domains.

Inviting users from other domains

SSO affects only the configured domains.
Users from other email domains can still join organizations using standard Console accounts (email/password or GitHub).

Multiple email domains

SSO is configured per domain.
All company domains must be included during setup to ensure consistent access.
Users with emails from domains not listed in the SSO configuration will continue using standard authentication.

Email aliases

Authentication always uses the primary email address from your IdP.
Aliases (e.g. john+project@company.com) map to the main account (e.g. john@company.com).
One Console account per user; aliases do not create separate accounts.

Authentication vs. Organization Access

SSO controls authentication only — it determines whether a user can log into the Console.
Authorization (organization and resource access) is managed separately within the Console.
Enabling SSO does not automatically grant users access to any organizations.
Users must still be explicitly invited to each organization by an owner, regardless of their authentication method.

Support

If you have questions about SSO setup or encounter any issues, please contact our support team. We're here to help ensure a smooth SSO integration for your organization.