Professional and Enterprise plans
Organization SSO is available only on Professional and Enterprise plans. Maxlona checks the subscription on configuration, discovery, token validation, just-in-time enrollment, and password enforcement—not only in the dashboard.
SSO controls and login stay unavailable. Existing configuration and verified-domain ownership are retained so a downgrade cannot create a second workspace for the same company domain.
Includes organization-level OIDC SSO and its enforcement controls.
Includes organization-level OIDC SSO and its enforcement controls.
If an organization downgrades, its saved configuration is preserved but becomes inactive immediately. Members should establish passwords before downgrade; an SSO-only member can use password recovery afterward. Upgrading to an eligible plan makes the saved configuration usable again.
What happens when you move to Professional
When the Professional subscription becomes active, Maxlona unlocks the organization's SSO controls. The upgrade does not automatically turn SSO on, redirect existing members, change their roles, or replace any SDK and API credentials.
Existing organization stays intact
Flags, environments, members, roles, management keys, and evaluation data remain unchanged. Existing members can continue using passwords until an Admin explicitly requires SSO.
Activation is deliberate
An organization Admin must save the provider, verify domain ownership, test the connection, and enable SSO. Each prerequisite is checked by the server.
Configure and turn on SSO
An organization Admin configures SSO from the admin-only Organization → Single Sign-On panel. A Global Admin can also configure it from Global Admin → Organizations → organization detail → Single Sign-On. Maxlona stores one OIDC provider configuration for each organization.
- 1
Enter provider details
Choose the provider preset, then save the issuer URL, client ID, client secret, allowed email domains, just-in-time policy, and default role.
- 2
Prove domain ownership
Publish the displayed
maxlona-domain-verification=…DNS TXT record, then choose Verify DNS. An unverified domain is never used for SSO discovery. - 3
Test the connection
Choose Test connection. Maxlona checks the issuer's OIDC discovery document before enforcement can be enabled.
- 4
Enable, then optionally enforce
Enable SSO after verification and testing. Turn on required SSO only when the organization is ready to block password sign-in for its members.
Recommended production rollout
- Register Maxlona as an OIDC web application in your identity provider and add the callback URL shown by your deployment to its allowed redirect URIs.
- In Maxlona, save the provider display name, HTTPS issuer URL, client ID, client secret, allowed company domains, JIT setting, and default JIT role.
- Publish the displayed DNS TXT record, select Verify DNS, and then select Test connection.
- Select Enable SSO, leave Require SSO off, and save. Password login remains available during this test period.
- Open a private browser window, choose Continue with work SSO on the login page, and test an allowed work email. Confirm the person reaches the correct organization with the expected role.
- Test several members and confirm an administrator recovery path. Then optionally select Require SSO and save to block password login for covered organization members.
Quick setup: Microsoft Entra ID and Okta
These configurations have been validated end to end with Maxlona's Authorization Code with PKCE flow. Use an OIDC Web application, keep Require SSO off during setup, and keep an existing administrator session open until a private-window test succeeds.
Microsoft Entra ID
- 1
Create the app registration
In the Azure portal, open Microsoft Entra ID → App registrations → New registration. Name it Maxlona SSO. For a workforce organization, normally choose Accounts in this organizational directory only.
- 2
Add the Web redirect URI
Open Authentication → Add a platform → Web and add
https://maxlona.com/login. Use the exact origin of your Maxlona deployment when it differs. Leave the implicit access-token and ID-token checkboxes off. - 3
Create a client secret
Open Certificates & secrets → New client secret. Immediately copy the secret's Value, not its Secret ID. Entra shows the value only once.
- 4
Add verified-email claims
Open Token configuration → Add optional claim → ID and add
email,verified_primary_email, andxms_edov. Maxlona accepts Entra's verified primary email or an email whose domain ownership Entra verifies. - 5
Copy identifiers into Maxlona
From the registration's Overview, copy the Application (client) ID. Use the Directory (tenant) ID in the tenant-specific issuer below. Do not use a client ID as the tenant ID.
https://login.microsoftonline.com/<directory-tenant-id>/v2.0 - 6
Confirm tenant access
The person signing in must exist in this Entra tenant, either as a member or invited guest. If the Enterprise Application requires assignment, assign the test user or an approved group. A tenant-mismatch error means the issuer tenant or signed-in Microsoft account is wrong.
| Maxlona field | Entra value |
|---|---|
| Provider | Microsoft Entra ID |
| Issuer URL | https://login.microsoftonline.com/<tenant-id>/v2.0 |
| Client ID | Application (client) ID |
| Client secret | Secret Value |
Okta
- 1
Create the OIDC application
In the Okta Admin Console, open Applications → Applications → Create App Integration. Choose OIDC – OpenID Connect and Web Application. Name it Maxlona.
- 2
Configure the authorization flow
Enable Authorization Code. Set the sign-in redirect URI to
https://maxlona.com/login. A sign-out URI is optional. Do not select SPA, Implicit, Client Credentials, or Resource Owner Password. - 3
Assign test users
Under Assignments, assign the test user or a test group. The Okta user must be active and have a primary email in a domain allowed by Maxlona. Assign broader groups only after the test succeeds.
- 4
Copy credentials and issuer
From the application's General tab, copy its Client ID and Client Secret. For the default custom authorization server, use the issuer below, replacing the hostname with your exact Okta domain.
https://<your-okta-domain>/oauth2/default - 5
Add an access policy when required
New Okta Integrator organizations may create the
defaultserver without a policy. Open Security → API → Authorization Servers → default → Access Policies. Add a policy assigned to the Maxlona client and an active rule allowing Authorization Code, users assigned to the app, and theopenid,profile, andemailscopes. - 6
Leave standard claims alone
Do not add custom
email,email_verified, orsubclaims. They are standard OIDC claims. Maxlona securely reads verified profile claims from the ID token or Okta UserInfo response and requires the UserInfo subject to match the signed ID token.
| Maxlona field | Okta value |
|---|---|
| Provider | Okta |
| Issuer URL | https://<your-okta-domain>/oauth2/default |
| Client ID | Application Client ID |
| Client secret | Application Client Secret |
/oauth2/default server has no matching active policy/rule, or the user is not assigned to the application. Check step 5 and the application assignment.Finish in Maxlona — both providers
- Open Organization → Single Sign-On, select the provider, and enter its display name, issuer, client ID, and client secret.
- Enter the company domain under Allowed email domains. This permits every verified identity in that domain; it is not an individual-email allowlist.
- Enable Just-in-time provisioning and choose Viewer as the safest initial Default JIT role. Existing member roles are not replaced.
- Save. A blank secret field labeled stored; leave blank to keep means the encrypted secret is present and is intentionally not returned to the browser.
- Add the displayed
maxlona-domain-verification=…TXT value at the domain root (@). DNS visibility can take from a few minutes up to the provider's TTL. Select Verify DNS. - Select Test connection, then enable SSO while leaving Require SSO off.
- Keep the current administrator session open. In a private window, start at
https://maxlona.com/login, choose work SSO, and test an assigned user in the allowed domain. - Sign out and repeat the login to confirm the same Maxlona account is reused. Test more than one administrator before optionally enabling Require SSO.
From work email to organization access
| Stage | What Maxlona does |
|---|---|
| Discover | Normalizes the work email and matches its domain only to an enabled, verified provider on an eligible plan. |
| Authenticate | The configured identity provider authenticates the person and returns a short-lived authorization code to Maxlona. |
| Validate | Exchanges the code with PKCE, then checks the ID token signature, issuer, audience, lifetime, nonce, signing algorithm, verified email and domain, and stable subject claim. When standard profile claims are returned through OIDC UserInfo, Maxlona requires its subject to match the signed ID token. |
| Enroll | Uses an existing membership or, when JIT is enabled, creates one with the configured Viewer or Editor role while respecting seat limits. |
| Enter Maxlona | Creates a Maxlona application session. The member can see the organization's flags and data according to their role. |
Existing membership roles are preserved. When JIT is disabled, an organization Admin or Global Admin must provision the person before their first SSO sign-in. The identity provider's token is validated for sign-in but is not used as the ongoing Maxlona session.
Your application integrations do not change
SSO controls interactive human sign-in only. SDK evaluations, REST evaluation, GraphQL, streaming connections, and automation evaluation continue using their existing organization-scoped keys. Enabling or requiring SSO does not rotate those credentials or change flag evaluation behavior.
Controls at every boundary
Secrets stay secret
Client secrets are encrypted with the shared ASP.NET Data Protection key ring and are never returned by the API.
Enforcement has prerequisites
The server rejects required SSO until the provider is enabled, successfully tested, and its domain is verified.
Recovery remains available
Global Admin password access is not blocked by an organization's required-SSO policy, preserving a recovery path.
Changes are accountable
Configuration saves, connection tests, and domain-verification actions are written to the audit log.
OIDC foundation
Microsoft Entra ID, Okta, Google Workspace, Auth0, Ping Identity, OneLogin, and generic OIDC use provider presets over the same standards-based validation. The sign-in client uses Authorization Code with PKCE; Maxlona exchanges the short-lived code directly with the provider, then validates the returned ID token and its original nonce.
SAML 2.0, SCIM, group mapping, and multiple identity providers per organization are not part of this phase.
HTTP entry points
These routes support the dashboard and sign-in experience. Tenant routes require an organization Admin and are fixed to that Admin's current organization. Cross-tenant routes require an authenticated globaladmin role.
| Method | Route | Purpose |
|---|---|---|
| GET / PUT | /organization/sso | Organization Admin: read or save the current organization's SSO configuration. |
| POST | /organization/sso/verify-domain | Organization Admin: verify the current organization's DNS ownership record. |
| POST | /organization/sso/test | Organization Admin: validate the current organization's OIDC discovery document. |
| GET / PUT | /admin/organizations/{organizationId}/sso | Read or save organization SSO configuration. |
| POST | /admin/organizations/{organizationId}/sso/verify-domain | Verify the DNS ownership record. |
| POST | /admin/organizations/{organizationId}/sso/test | Validate OIDC discovery and mark the connection tested. |
| POST | /auth/sso/discover | Find the verified provider for a work-email domain. |
| POST | /auth/sso/login | Exchange the authorization code, validate the returned identity, and create the Maxlona session. |