Hecho con Chinaski

Configurar SSO

Chinaski soporta single sign-on a través de cualquier provider estándar de OAuth 2.0 / OpenID Connect (flujo authorization-code). Un provider por site. Esta guía cubre ambos lados: registrar la app con tu identity provider, y llenar los settings.

Qué registrar en tu identity provider

  1. Crea una aplicación (client) OAuth/OIDC del tipo estándar "authorization code".
  2. Dale a tu provider la redirect URL que usará el CMS:
https://<your-site-domain>/auth/sso/callback

(Tu provider puede llamarlo Redirect URI, Callback URL o similar.) Debe ser la dirección exacta en la cual tu admin es alcanzable.

  1. Anota los scopes otorgados: Chinaski hace sign-in con openid email profile y lee los claims sub, email y (si están presentes) email_verified del usuario.
  2. Copia los tres endpoints que tu provider expone: casi todos los providers compatibles publican el mismo trío bajo nombres como "Authorization endpoint," "Token endpoint" y "Userinfo endpoint."

Qué llenar en Chinaski

Bajo Settings → Security, activa el checkbox de OAuth. Los campos de endpoints aparecen una vez que está encendido:

  • Client ID: el ID de aplicación/client de tu provider.
  • Client Secret: pégalo una vez; se almacena cifrado y el campo queda en blanco después (semántica de "leave blank to keep existing", como otras credenciales).
  • Authorization URL: el endpoint de authorize de tu provider (normalmente termina en /authorize).
  • Token URL: el token endpoint de tu provider.
  • Userinfo URL: el userinfo endpoint de tu provider.

El botón de SSO aparece en la página de sign-in solo cuando todo lo anterior más el secret está guardado: un config parcialmente llenado se auto-chequea en lugar de funcionar a medias.

Cómo funciona el sign-in después

  1. La página de login del admin muestra un botón "Sign in with SSO" (junto al formulario normal de contraseña, que sigue funcionando).
  2. Hacer clic en él envía el navegador a tu provider, con un state aleatorio de un solo uso para mantener segura la transacción.
  3. Después de que el provider autentica a la persona, el flujo verifica el state de la respuesta e intercambia el code por una identidad.
  4. Luego ocurre la resolución de cuenta, en este orden:
    • Usuario ya linkeado: reconocido por su identidad del provider (sub).
    • Cuenta existente por email: si el email coincide con el email de un usuario y el provider lo confirma. Esa cuenta se linkea a la identidad de SSO; su contraseña no se toca.
    • Persona totalmente nueva: se crea una cuenta automáticamente como editor con una contraseña aleatoria inutilizable; el audit log registra la auto-creación.
  5. La sesión es la sesión estándar de admin de 8 horas; los usuarios de SSO son usuarios normales una vez que han hecho el sign-in.

Reglas de cuenta que vale la pena conocer

  • Editor por defecto. Las cuentas creadas por SSO son editores; promociona a la gente a admin manualmente.
  • Solo un slot de provider. Si necesitas dos identity providers, eso no lo soporta el software actual; elige uno.
  • El matching por email confía en las semánticas de confirmación del provider. Si el provider explícitamente marca una dirección como no verificada, el sign-in se rechaza (y se registra). Si el provider no envía ningún flag de verificación, lo cual muchos providers OIDC hacen para cuentas confirmadas, Chinaski trata la dirección como verificada. Si tu IdP permite emails no verificados y no quieres eso, registra allí el enforcement de verificación de email.
  • Los usuarios provisionados no tienen contraseña. Se fija una contraseña aleatoria que nadie conoce; esos usuarios entran solo por SSO, o un admin les envía un email con un reset de contraseña.
  • ¿Bloqueado o deslogueado? Aplican las reglas estándar de sesión: la suspensión sigue bloqueando a los usuarios de SSO exactamente igual que a los usuarios de contraseña; los cambios/resets de contraseña desloguean a la gente sin importar cómo hicieron el sign-in.

Solución de problemas

  • El botón de SSO no aparece: algún campo requerido (o el checkbox de activación) está vacío. Revisa los cinco.
  • "Invalid OAuth state" después de volver del provider: generalmente el callback corrió en una sesión/navegador distinta de la que inició (cookies bloqueadas, o el dominio del admin no coincide), o el usuario tardó demasiado en la página del provider. Intenta de nuevo; si persiste, verifica que la URL del admin en la barra de direcciones coincida exactamente con el redirect URI registrado.
  • "Sign in with SSO" falta en la página de login: la configuración está incompleta o el checkbox está apagado; los campos solo se vuelven parte del flujo cuando todos están llenos.
  • "Email not verified" para un usuario conocido: el IdP dijo explícitamente que el email de la cuenta no está verificado; corrígelo del lado del provider (o fija su email en el CMS a uno verificado).
  • La cuenta creada es un editor, no lo que se esperaba: esa es la regla de auto-provisión; ajusta los roles en la pantalla de usuarios del admin.

La versión corta

Registra /auth/sso/callback como el callback en cualquier provider estándar de OAuth/OIDC, llena cinco campos bajo Settings → Security (toggle de activación + client ID + secret cifrado + tres URLs de endpoints), y la página de login gana un botón de SSO que hace el sign-in de los usuarios, linkeando cuentas existentes por email confirmado y creando editores automáticamente para personas nuevas.

Lee este sitio en