Single Sign-On
Connect nano to your identity provider with OpenID Connect (OIDC) for centralized login, JIT provisioning, and group-based access.
Single Sign-On (SSO)
nano supports single sign-on through OpenID Connect (OIDC). You register nano as an OIDC application in your identity provider (IdP), add the provider in nano, and your team signs in with their existing corporate accounts.
nano implements OIDC only — there is no SAML support. Some IdP admin consoles (Google Workspace in particular) default their "custom app" wizard to SAML; ignore that path and connect nano through the provider's OIDC / OAuth 2.0 endpoints instead. Every major IdP (Google Workspace, Microsoft Entra ID, Okta) supports OIDC.
Availability
SSO requires the sso capability, available on the Starter tier and above. Adding or editing providers requires the settings:system permission.
How SSO accounts work
- Just-in-time (JIT) provisioning — an SSO user is created automatically on their first successful login. You do not pre-create accounts.
- IdP-managed identity — SSO users cannot change their email or password in nano; those are owned by the identity provider.
- Group-mapped access — an SSO user's roles come from group mappings (IdP group → nano group/role), not from manual assignment.
Add a provider
Go to Settings → Single Sign-On (/settings/oidc) and add a provider. The fields are the same for every IdP:
| Field | What it is |
|---|---|
| Name | Display name shown on the login screen (e.g. "Acme Google"). |
| Slug | Short identifier used in nano's login and callback URLs. Lowercase, no spaces (e.g. google, okta, entra). |
| Issuer URL | The IdP's OIDC issuer. nano auto-discovers its endpoints at <issuer>/.well-known/openid-configuration. |
| Client ID / Client Secret | From the OAuth application you register in the IdP. |
| Scopes | openid email profile at minimum. Add a groups scope if you want group mapping. |
| Group claim | Optional. The ID-token claim that carries group names (usually groups), consumed by group mappings. |
The redirect (callback) URI
Your IdP needs to know where to send users back after they authenticate. In every provider you register, add this exact redirect URI:
https://<your-nano-host>/auth/callback/<slug>For example, with host siem.acme.com and slug google:
https://siem.acme.com/auth/callback/googleThe redirect URI must match exactly — scheme, host, and the <slug> segment. A mismatch is the most common cause of a failed sign-in (redirect_uri errors). If you change the provider's slug, update the URI in the IdP too.
Group mapping
After adding a provider, map IdP groups to nano groups/roles so SSO users inherit the right permissions. Group mapping requires:
- The IdP to emit a groups claim in the ID token, and
- The provider's Group claim field set to that claim name (usually
groups).
Support for groups in the ID token varies by IdP — see each provider guide below.
Provider guides
Security notes
- nano validates every ID token's signature against the provider's published JWKS, pins the signing algorithm to RS256, and checks the issuer, audience, expiry, and a per-login nonce (replay protection).
- The authorization request uses PKCE.
- Discovery and JWKS fetches are SSRF-guarded; issuer URLs must resolve to a public host.