User Guides

Single Sign-On (SSO)

Provisioning Modes (Basic vs Just‑in‑Time)


This page explains how Naxai SSO handles user authentication and user provisioning.

Naxai supports two SSO modes:

  • Basic SSO (no JIT) — users must be created manually in Naxai
  • SSO with Just‑in‑Time (JIT) provisioning — users are created automatically on first login

Supported Identity Providers

Naxai Single Sign-On (SSO) is compatible with leading identity providers, allowing you to integrate seamlessly with your existing authentication infrastructure. Currently supported providers include:

  • Okta – Enterprise-grade identity and access management platform
  • Microsoft Entra ID (Azure AD) – Native integration with Microsoft ecosystems
  • Google Workspace – Simple SSO setup for organizations using Google accounts

Each provider supports standard SAML 2.0-based authentication and can be configured to enable secure, centralized access to your Naxai instance. For detailed configuration steps, refer to the dedicated guides for each provider.


Overview of SSO Modes

ModeUser creationUser updatesTypical use case
Basic SSOManual (admin‑created)None via SSONoneStrict access control, limited user base
SSO with JITAutomatic on first loginBasic attributes updated on loginSelf‑service onboarding, larger teams

⚠️

SCIM provisioning is not supported.
In both modes, there is no background synchronization of users, groups, or roles.


Option 1 — Basic SSO (No JIT Provisioning)

In Basic SSO mode, SSO is used only for authentication. Naxai will never create users automatically.

How Basic SSO works

  1. A Naxai administrator manually creates users in Naxai
  2. Each user is associated with an email / identifier
  3. The user logs in with email address
  4. Naxai authenticates the user via the IdP
  5. If a matching user exists, access is granted
  6. If no matching user exists, access is denied

Important characteristics

✅ Users must exist in Naxai before login

✅ Full control over who can access the platform

✅ Suitable for small or security‑sensitive environments

❌ No automatic onboarding

❌ No attribute updates from the IdP


Failure scenario (expected behavior)

If a user authenticates successfully at the IdP but does not exist in Naxai:

  • Authentication succeeds at the IdP
  • Authorization fails at Naxai
  • The user cannot log in

Option 2 — SSO with Just‑in‑Time (JIT) Provisioning

With JIT provisioning enabled, Naxai automatically creates and updates users during SSO login.

High‑level flow

  1. The user login with email address
  2. Naxai redirects the user to the Identity Provider (IdP)
  3. After successful authentication, the IdP returns a SAML assertion or OIDC ID token
  4. Naxai validates the assertion/token
  5. Naxai looks up the user by a unique identifier
  6. If the user does not exist, Naxai creates the user
  7. If the user exists, Naxai updates supported attributes
  8. The user is signed in and granted access

JIT provisioning flow

sequenceDiagram
  autonumber
  actor U as User
  participant A as Naxai App
  participant I as Identity Provider (IdP)
  participant D as Naxai User Directory

  U->>A: Login with email address
  A->>I: Redirect to IdP (Authn request)
  I->>U: Authentication prompt (MFA, policies)
  U->>I: Authenticate
  I-->>A: Return SAML Assertion / OIDC ID Token
  A->>A: Validate token / assertion

  A->>D: Lookup user by unique identifier
  alt User exists
    D-->>A: User found
    A->>D: Update profile attributes
    A-->>U: Signed in (existing user)
  else User does not exist
    D-->>A: No match
    A->>D: Create user (JIT)
    A->>D: Assign default role & tenant
    A-->>U: Signed in (new user)
  end

  note over A,D: No SCIM — no background user or group sync



User Identity & Matching (Both Modes)

Naxai must match the authenticated user to a Naxai user record.

Unique identifier

Primary: email

⚠️

Important: If the identifier changes (e.g., email rename), Naxai may treat the user as a new account unless corrected manually.


Common IdP claim/attribute names

  • email (unique identifier)
  • given_name
  • family_name
{
  "sub": "00u123abcXYZ",
  "email": "[email protected]",
  "given_name": "John",
  "family_name": "Doe"
}

Required Attributes (JIT Only)

These attributes are required only when JIT provisioning is enabled.

Required

  • email (unique identifier)
  • given_name
  • family_name
  • naxai_subaccount_ids Provide a list of subaccounts that the user has access to, use the pipe | as separator.
    E.g. f093449-344b-4307-a24b-c2acf02cd9cd**|**bc47ffab-d7f1-4a8e-bb77-647de6729cd2
  • naxai_role
    The role of the user (owner, admin...)
  • phone (optional)
  • preferredLanguage (optional)
    Supported languages FR, EN ,or NL



User Lifecycle Summary

Basic SSO

  • User creation: ❌ Manual only
  • User update via SSO: ❌ No
  • User deletion: ❌ Manual

SSO with JIT

  • User creation: ✅ On first login
  • User update: ✅ First name / last name on login
  • User deletion: ❌ Manual

Deprovisioning / Offboarding (Both Modes)

Because SCIM is not supported, deprovisioning relies on IdP access control and/or Naxai admin actions.

Recommended approach

  1. Disable the user in the IdP or remove the user from the Naxai application assignment
  2. (Optional) Disable or remove the user in Naxai for internal visibility

Result

  • The user cannot authenticate
  • No automatic deletion occurs


FAQ

Which mode should I choose? Choose Basic SSO if you need strict control over user creation. Choose JIT if you want frictionless onboarding.

Can I switch modes later? Yes. Switching affects future logins only; existing users are not modified automatically.

Can I sync groups or roles from my IdP? No. Group‑based provisioning requires SCIM or a custom integration.


Next steps

  • Decide which SSO mode fits your organization
  • Configure the IdP accordingly
  • For JIT: ensure required attributes are sent
  • Define an offboarding runbook (IdP disable + optional Naxai disable)