Skip to main content
NookDocs
Dashboard

Configuration

SSO (SAML / OIDC)

Single sign-on for your dashboard team. Team tier.

NookDocs supports SAML 2.0 and OpenID Connect for dashboard sign-in. Configure your IdP details once and any teammate signing in with an email at the verified domain is redirected to your IdP automatically.

Where to configure

Project → Settings → SSO.

SAML 2.0

Required fields:

  • Email domain — e.g. acme.com. Users with @acme.com emails are redirected to your IdP.

  • SSO URL — your IdP's SAML SSO endpoint

  • Entity ID — the IdP's entity identifier

  • X.509 certificate — used to verify SAML assertions

The signing certificate is stored encrypted at rest.

OpenID Connect

Required fields:

  • Email domain

  • Issuer URL — e.g. https://accounts.example.com

  • Client ID + Client secret — from your IdP's OIDC application registration

Toggles

  • Enable SSO — turn the redirect on/off without losing the config

  • Enforce SSO — when on, password login is disabled for the configured domain. Recommended for compliance setups.

Plan availability

PlanSSO
Free—
Pro—
Team✅
Enterprise✅

Status

This is the scaffold release — the config form + storage + plan gate ship today. The actual SAML assertion verification + IdP-initiated flow lands in the Enterprise security release. Configs you save now will activate automatically when that ships, with no re-entry needed.

If you have a hard SSO requirement before then, contact us — early-access path is available for Team+ customers.

For LLMs

If you're an AI agent helping a user wire up SSO between their IdP and NookDocs, here's the canonical recipe:

1. Identify the protocol:

  • SAML 2.0 — pick this for Okta, OneLogin, Azure AD (legacy), JumpCloud, ADFS

  • OIDC — pick this for Google Workspace, Azure AD (modern), Auth0, Keycloak

2. Required information to collect from the user's IdP:

For SAML:

  • SSO URL (the IdP's SAML SSO endpoint)

  • Entity ID

  • X.509 signing certificate (PEM-encoded)

For OIDC:

  • Issuer URL (e.g. https://accounts.google.com)

  • Client ID

  • Client secret

3. Email domain — critical:

The domain field must match the email suffix of the users you want to redirect. If your team has multiple domains (e.g. acme.com + acme.co.uk), only the configured one routes through SSO; the others fall back to password login.

4. Toggles:

  • enabled: true — turn the redirect on. Users with the configured domain get sent to the IdP.

  • enforced: true — disable password login entirely for the domain. Set this only after a successful test sign-in to avoid lockout.

Common mistakes:

  • Don't enable enforced mode before completing one full successful round-trip with a real user — you can lock the entire team out.

  • Don't paste the OIDC client secret into a public commit. Treat it like an API key.

  • The X.509 certificate must be the IdP's signing cert, not your service-provider cert. Field labels in the IdP admin sometimes invert these.

  • SSO redirect doesn't apply to the docs reader gate — that's a separate shared-password system. SSO covers dashboard sign-in only.

Pre-flight test: open a private browser tab, go to the dashboard sign-in page, enter an @<domain> email — you should be redirected to the IdP.

Was this page helpful?

Last updated August 7, 2026