AdministrationTalon Studio v1.0.2-beta
Single Sign-On
Sign in with built-in credentials, or connect GitHub, Google or Microsoft Entra ID single sign-on — an Enterprise feature, which is in development.
What it is
Talon authenticates through next-auth. Out of the box it supports username or email plus password. Admins can add OAuth / OIDC single sign-on with GitHub, Google or Microsoft Entra ID.
Setting up SSO needs an Enterprise licence key, and Enterprise is in development — not on sale yet. On the Community Edition, /settings/sso shows "SSO is an Enterprise feature" and everyone signs in with a local account. What the key gates is SSO taking on new accounts; an identity already linked to an account keeps signing in if a key lapses. SAML, SCIM provisioning and enforced SSO are not built.
How it works
Credentials — the built-in provider. Passwords are bcrypt-hashed, with optional TOTP two-factor.
OAuth / OIDC providers — GitHub, Google and Microsoft Entra ID, using the authorisation-code flow with PKCE (S256) and a signed state parameter. Talon asks GitHub for user:email, and Google and Entra ID for openid email profile. Client secrets are encrypted at rest and each provider has its own enable switch.
Matching a sign-in to an account. An identity already linked signs straight in. Otherwise Talon links it to the local account with the same email; failing that, it creates a new account if self-registration is allowed. Linking and creating both need the Enterprise key.
Verified email required. Both linking to an existing account and self-registering a new one require the identity provider to assert the email is verified — an unverified email is refused rather than linked or provisioned. For GitHub, Talon ignores the profile email and reads the account's email list, accepting only a verified address and preferring the primary one.
Self-registration — off by default. When on, a new SSO user gets the provider's Default role for new users (readonly by default; analyst, engineer or admin can be chosen) and counts against the user limit. Their login handle is the part of the email before the @; the provider's full name becomes their display name.
SSO owns the display name: it re-syncs from the provider at every sign-in. The avatar is filled from the provider only when the user has none.
If a linked account still had a forced password change pending (the bootstrapped admin, say), the first successful SSO sign-in removes the stored password and switches the account to SSO.
Session settings apply to every sign-in method:
Setup
1
Open Settings → SSO (/settings/sso, admin only) and click Add SSO provider.
2
Pick the provider. The dialog shows the callback URL to register with it — https://<your-instance>/api/auth/sso/<github|google|entra>/callback — with a copy button. Create the OAuth application at the provider with that redirect URI.
3
Paste the Client ID and Client secret (and the Tenant ID for Microsoft Entra ID), switch on Enable this provider, and optionally Allow self-registration with a default role.
4
Confirm NEXTAUTH_URL and AUTH_TRUST_HOST match your deployment so the redirect and cookies work. An enabled provider then appears as a button on the sign-in page.
Usage
Users sign in with a provider button; the callback links their account and syncs profile details. They have ten minutes to finish at the provider before the attempt expires.
A refused sign-in returns to the sign-in page with the reason: self-registration is off, the email isn't verified, the account is disabled, the user limit is reached, or — on the Community Edition — the identity isn't linked to an account yet.
Credentials users enrol TOTP on their profile; SSO users defer MFA to their identity provider.
Tip
If you allow self-registration, keep the default role at readonly — a new SSO sign-in can then see the app but can't act until an admin promotes them, so onboarding stays self-service without handing out edit rights.
Display names re-sync on every login
For SSO-linked accounts, the identity provider's name overwrites the Talon display name at each sign-in. Rename people at the provider — there is no Talon-side field that would survive their next login.