SSO & OAuth

You can let your team sign in to the Chinaski admin with your existing identity provider instead of separate Chinaski passwords. Chinaski supports standard OAuth 2.0 authorization-code logins against OpenID Connect–style providers.

Where SSO settings live

SSO is configured in Settings → Security, under the Single Sign-On (OAuth / OIDC) section.

Enable SSO: turn SSO logins on or off
Client ID
Client Secret
Authorization URL
Token URL
Userinfo URL

Fill in all five provider fields from your identity provider’s OAuth/OIDC application. SSO is only considered configured when SSO is enabled and every one of those five fields has a value.

Note: the SSO section does not appear in Settings when your CMS instance runs in air-gapped mode.

Configuring your provider

All five fields come from an OAuth/OIDC client application you create in your identity provider. When you register that application with your provider, use the callback (redirect) URI:

https://your-cms-url/auth/sso/callback

That is the exact absolute callback URL Chinaski uses for both the authorization step and the token exchange.

The Client Secret is stored encrypted. To change it, enter a new value; leaving the field blank keeps the existing secret.

What users see

Once SSO is configured, a “Sign in with SSO” button appears on the admin login page. Clicking it starts the login at your identity provider, where the requested scopes are openid, email, and profile.

If something goes wrong, the user is returned to the login page with one of these messages:

SSO is not configured
Invalid OAuth state: possible CSRF attack
OAuth authorization denied
OAuth token exchange failed (or: no access token)
OAuth userinfo request failed
OAuth userinfo did not return a user identifier
SSO login requires a verified email address from your identity provider

When the sign-in succeeds, the user is taken to /admin and the login is recorded (including the IP address) in the auth log. SSO sessions last 8 hours from login.

How visitors become users

When someone signs in with SSO, Chinaski finds their account in this order:

By existing SSO linkage. If an account is already linked to that provider identity, it is used.
By verified email. The provider must either confirm the email address or omit the verification flag; if the provider explicitly says the email is not verified, sign-in is refused with the “verified email address” message above. A matching account is then linked to the SSO identity.
New account. If nothing matches, an account is created automatically with the editor role. The username comes from the email’s local part (with invalid characters removed), falls back to sso_user, and gets a number appended if the name is taken (up to 100 attempts).

Every account is one or the other: automatic account creation means visitors who complete an SSO login will get editor access to your site. Make sure your identity provider only allows the people you want to be editors. An SSO auto-created account is also recorded as an audit event.

Suspending a user also blocks their SSO logins, since suspended users are denied with the same access-denied message as any failed login, after a short delay.

Linked accounts

A signed-in user can see whether their account is linked to SSO on their own Account page, under the Single Sign-On heading (“Linked to oauth”).

Turning SSO off

Clear the Enable SSO checkbox in Settings → Security to remove the login button and disable SSO sign-in. You can also reset the whole Security tab back to its defaults with the Security section’s reset control, which turns SSO off and clears the Client ID, Authorization URL, Token URL, and Userinfo URL fields.