Configuring SSO

Notavia lets your team sign in to the dashboard with your own corporate identity provider (IdP) over SAML 2.0 or OIDC. This is dashboard sign-in only — your application’s end-users are unaffected, and your API keys keep working exactly as before.

Only an organization Owner can configure SSO. Find it in the dashboard under Settings → Authentication.

How it works

1. You register Notavia as an application in your IdP (Okta, Microsoft Entra ID, or any OIDC provider).
2. You paste the IdP’s metadata (SAML) or discovery URL + client credentials (OIDC) into Settings → Authentication and save it as a draft.
3. You click Test login to confirm the round-trip works.
4. You Activate. From then on, anyone whose work email matches your configured domain can sign in via your IdP. New users are provisioned automatically (just-in-time) the first time they sign in.

When a team member signs in through your IdP for the first time, Notavia creates their account, links it to your organization, and assigns a role based on their IdP group membership (see Role mapping below). Users with no matching group get the Viewer role.

Okta (SAML 2.0)

1. In the Okta Admin Console, go to Applications → Create App Integration → SAML 2.0.
2. Set the Single sign-on URL (Assertion Consumer Service) to: https://app.notavia.saas-infrastructure.com/auth/saml/{your-org-id}/Acs (your org id is shown on the Settings → Authentication page).
3. Set the Audience URI (SP Entity ID) to: https://app.notavia.saas-infrastructure.com/auth/saml/{your-org-id}
4. Under Attribute Statements, send the user’s email as the NameID (format: EmailAddress).
5. Under Group Attribute Statements, send group membership in a claim named groups (filter to the groups you want Notavia to see).
6. Finish the wizard, then open the app’s Sign On tab and copy the Metadata URL (or download the metadata XML).
7. In Notavia → Settings → Authentication → Configure SSO, choose SAML, enter your email domain (e.g. acme.com), and paste the metadata URL or XML. Save, Test login, then Activate.

How to verify it worked

Open the dashboard login page in a private window, type a @acme.com email, and confirm the Continue with SSO button appears. Complete a sign-in; the new user should land in the dashboard. An Owner can confirm the audit trail in the database:

SELECT event_kind, email_domain, occurred_at
FROM auth_audit_logs
WHERE organization_id = '{your-org-id}'
ORDER BY occurred_at DESC
LIMIT 10;

Microsoft Entra ID (OIDC)

1. In the Entra admin center, go to App registrations → New registration.
2. Set the Redirect URI (type Web) to: https://app.notavia.saas-infrastructure.com/auth/oidc/{your-org-id}/callback
3. Note the Application (client) ID and the Directory (tenant) ID. Your issuer / discovery URL is: https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration
4. Under Certificates & secrets, create a client secret and copy its value (you can only see it once).
5. Under Token configuration, add the groups claim so group membership is included in the token.
6. In Notavia → Settings → Authentication → Configure SSO, choose OIDC, enter your email domain, the discovery URL, the client ID, and the client secret. Save, Test login, then Activate.

How to verify it worked

Same as above — try a sign-in from a private window with a matching email and confirm the user lands in the dashboard with the expected role.

Generic OIDC provider

Any standards-compliant OIDC provider works. You need:

• A discovery URL ending in /.well-known/openid-configuration that exposes issuer, authorization_endpoint, token_endpoint, and jwks_uri.
• A client ID and client secret for a confidential client using the authorization code flow with PKCE.
• The redirect URI https://app.notavia.saas-infrastructure.com/auth/oidc/{your-org-id}/callback registered with the provider.
• The scopes openid email profile groups (Notavia requests these).

Provide the user’s email in the email claim and group membership in a claim named groups (or set a custom claim name in the group claim field of the configuration wizard).

Role mapping

On Settings → Authentication, the Role mapping card maps IdP group values to Notavia roles. For each mapping you set:

• Group value — the exact value sent in your IdP’s group claim (e.g. notavia-admins).
• Role — one of Owner, Admin, Developer, Billing, Viewer.
• Priority — when a user belongs to several mapped groups, the mapping with the lowest priority number wins.

A user whose groups match no mapping signs in as Viewer. Roles are re-evaluated on every sign-in, so your IdP remains the source of truth.

Force-SSO

The Force-SSO toggle requires everyone at your email domain to sign in via your IdP — password sign-in is rejected for them. Two safeguards:

• Owners are always exempt. An Owner can always sign in with email + password as a break-glass fallback, even when force-SSO is on. This prevents lockout if your IdP is misconfigured or unavailable.
• You cannot enable force-SSO unless your SSO configuration is Active and your organization has at least one Owner.

If force-SSO ever locks out your team, an Owner signs in with a password and toggles it off.

What’s not included (yet)

These are planned for a future release:

• SCIM user/group provisioning (Notavia uses just-in-time provisioning).
• Single Logout (SLO) — signing out of Notavia does not sign you out of your IdP.
• IdP-initiated sign-in (start from your IdP’s app launcher) — Notavia is service-provider-initiated only.
• Multiple email domains per organization (one domain per configuration).
• SSO for the public API — API keys remain the only auth method for /v1/*.