Feito com Chinaski

Configurar SSO

O Chinaski suporta single sign-on através de qualquer provedor OAuth 2.0 / OpenID Connect padrão (fluxo de código de autorização). Um provedor por site. Este guia cobre ambos os lados: registrar a aplicação no seu provedor de identidade e preencher as configurações.

O que registrar no seu provedor de identidade

  1. Crie uma aplicação (cliente) OAuth/OIDC do tipo padrão "authorization code".
  2. Dê ao seu provedor a URL de redirecionamento que o CMS usará:
https://<your-site-domain>/auth/sso/callback

(Seu provedor pode chamá-la de Redirect URI, Callback URL ou similar.) Ela precisa ser o endereço exato no qual seu admin é alcançável.

  1. Anote os escopos concedidos: o Chinaski entra com openid email profile e lê os claims sub, email e (se presente) email_verified do usuário.
  2. Copie os três endpoints que seu provedor expõe: quase todos os provedores compatíveis publicam o mesmo trio sob nomes como "Authorization endpoint", "Token endpoint" e "Userinfo endpoint".

O que preencher no Chinaski

Em Settings → Security, habilite a caixa OAuth. Os campos de endpoint aparecem assim que ela está ligada:

  • Client ID: o ID de aplicação/cliente do seu provedor.
  • Client Secret: cole-o uma vez; ele é armazenado criptografado e o campo fica em branco depois (semântica de "deixe em branco para manter o existente", como outras credenciais).
  • Authorization URL: o endpoint authorize do seu provedor (tipicamente termina em /authorize).
  • Token URL: o endpoint de token do seu provedor.
  • Userinfo URL: o endpoint de userinfo do seu provedor.

O botão SSO aparece na página de login apenas quando todos os itens acima mais o segredo estão salvos: uma config parcialmente preenchida se autoconfere em vez de funcionar pela metade.

Como o login funciona depois

  1. A página de login de admin mostra um botão "Sign in with SSO" (ao lado do formulário normal de senha, que continua funcionando).
  2. Clicar nele manda o navegador ao seu provedor, com um estado aleatório único para manter a troca segura.
  3. Depois que o provedor autentica a pessoa, o fluxo verifica o estado da resposta e troca o código por uma identidade.
  4. Então a resolução de conta acontece, nesta ordem:
    • Usuário já vinculado: reconhecido pela identidade do provedor (sub).
    • Conta existente por e-mail: se o e-mail casa com o e-mail de um usuário e o provedor o confirma. Essa conta fica vinculada à identidade SSO; a senha dela permanece intocada.
    • Pessoa completamente nova: uma conta é criada automaticamente como editor com uma senha aleatória inutilizável; o audit log registra a criação automática.
  5. A sessão é a sessão de admin padrão de 8 horas: usuários SSO são usuários normais depois de conectados.

Regras de conta que vale conhecer

  • Editor por padrão. Contas criadas por SSO são editores; promova pessoas a admin manualmente.
  • Apenas um slot de provedor. Se você precisa de dois provedores de identidade, isso não é algo que o software atual suporta: escolha um.
  • A correspondência de e-mail confia na semântica de confirmação do provedor. Se o provedor explicitamente marca um endereço como não verificado, o login é recusado (e registrado). Se o provedor não envia nenhuma flag de verificação (o que muitos provedores OIDC fazem para contas confirmadas), o Chinaski trata o endereço como verificado. Se o seu IdP permite e-mails não verificados e você não quer isso, ative lá a exigência de verificação de e-mail.
  • Usuários provisionados não têm senha. Uma senha aleatória que ninguém conhece é definida; esses usuários entram apenas por SSO, ou um admin lhes envia uma redefinição de senha por e-mail.
  • Bloqueados ou desconectados? As regras padrão de sessão se aplicam: a suspensão ainda bloqueia usuários SSO exatamente como bloqueia usuários de senha; troca/redefinição de senha desconecta as pessoas independentemente de como entraram.

Solução de problemas

  • O botão SSO não aparece: um campo obrigatório (ou a caixa de habilitar) está vazio. Confira os cinco.
  • "Invalid OAuth state" após voltar do provedor: geralmente o callback executou numa sessão/navegador diferente daquele em que começou (cookies bloqueados, ou domínio de admin divergente), ou o usuário demorou demais na página do provedor. Tente novamente; se persistir, confira se a URL de admin na barra de endereços corresponde exatamente à redirect URI registrada.
  • "Sign in with SSO" ausente na página de login: a configuração está incompleta ou a caixa está desligada; os campos só passam a fazer parte do fluxo quando todos estão preenchidos.
  • "Email not verified" para um usuário conhecido: o IdP disse explicitamente que o e-mail da conta não é verificado; corrija no lado do provedor (ou defina no CMS um e-mail verificado para o usuário).
  • A conta criada é editor, não o que era esperado: essa é a regra de autoprovisionamento; ajuste os papéis na tela de usuários do admin.

A versão curta

Registre /auth/sso/callback como callback em qualquer provedor OAuth/OIDC padrão, preencha cinco campos em Settings → Security (chave de ativação + client ID + segredo criptografado + três URLs de endpoint), e a página de login ganha um botão SSO que conecta os usuários, vinculando contas existentes por e-mail confirmado e criando editores automaticamente para pessoas novas.

Leia este site em