Login social e corporativo

O Authio atua como intermediário (broker). Para a sua aplicação, um login pelo Google ou pelo diretório de uma empresa é um login comum do Authio: o mesmo pedido de autorização, o mesmo código, tokens emitidos pelo realm para uma conta local. Por trás, o Authio leva a pessoa ao provedor, valida o que volta e decide a qual conta do realm ela pertence.

Você registra um provedor uma vez por realm e depois escolhe quais clients o mostram na tela de login, e em que ordem. A sua aplicação não muda nada para ganhar uma nova forma de entrar.

Provedores aceitos

Google, Microsoft Entra ID, GitHub e Apple são predefinições: os endpoints, os escopos e os nomes das claims já são conhecidos. O tipo OpenID Connect genérico lê os endpoints a partir da authority, o endereço-base onde o provedor publica o documento de descoberta, então ele serve para Okta, Auth0, Keycloak, outro realm do Authio ou qualquer diretório compatível.

Adicionar um provedor

1. 1

   Registre o provedor no Authio

   Abra Provedores de identidade e escolha Criar. Escolha o realm e o tipo e dê o rótulo do botão que as pessoas vão ver. O alias é derivado do nome e passa a fazer parte do endereço de callback; nem o alias nem o tipo podem mudar depois que o provedor é registrado.

2. 2

   Registre o Authio no provedor

   No console do próprio provedor, crie uma aplicação OAuth ou OIDC e registre o endereço de callback. A visão do provedor no Authio mostra esse endereço, pronto para copiar:

   Endereço de callbackTexto simples

   https://authio.api.hyperio.tech/realms/acme/broker/google/callback

3. 3

   Preencha as credenciais e o modo de vínculo

   Cole o client ID e o segredo emitidos pelo provedor (para a Apple, o Team ID, o Key ID e a chave privada). Para Microsoft Entra ID e OpenID Connect genérico, informe a authority. Depois escolha como as contas são vinculadas.

   O segredo é gravado uma vez e nunca mais exibido. Authorities e endpoints que apontam para uma rede privada — um IP não público, localhost, nomes .local ou .internal — são recusados ao salvar.

4. 4

   Ofereça o provedor num client

   Registrar um provedor o deixa disponível no realm; oferecê-lo o torna visível. Em Clients, abra o client, escolha Editar e vá até Opções de login: ofereça os provedores que quiser e coloque-os em ordem. A lista é salva inteira.

5. 5

   Teste

   Comece um login pela sua aplicação. Embaixo do botão de entrar, o login hospedado agora mostra Continuar com Google, ou o rótulo que você escolheu.

Quando um pedido de autorização nomeia uma organização, o login mostra os provedores dessa organização, na ordem dela, no lugar dos do client.

Vínculo de contas e contas novas

Na primeira vez que alguém chega por um provedor, o Authio precisa decidir em que conta a pessoa entra. Uma identidade já vinculada a uma conta é sempre respeitada primeiro — mesmo que o e-mail tenha mudado no provedor. Para uma identidade nunca vista, quem decide é o modo de Vínculo de contas do provedor:

Contas criadas no primeiro login

• A conta é criada sem senha e vinculada ao client pelo qual a pessoa chegou. O webhook user_created é publicado.
• Ela conta para a cota de usuários do plano dono do realm. Sem vaga, o login é recusado com uma mensagem que a pessoa entende.
• O nome de usuário é o do provedor; senão, o e-mail; senão, o alias do provedor e o subject unidos por um sublinhado.
• O e-mail só é marcado como confirmado quando o provedor é confiável e declarou que o endereço foi verificado.

Depois do provedor

Voltar do provedor não é o fim do login. O Authio trata esse retorno como qualquer outro primeiro fator:

• Ele conta como um fator, faça o provedor o que fizer, e é registrado como fed no amr; o alias do provedor vai na claim idp. As etapas de segundo fator do client continuam valendo: Google mais uma aprovação por push resulta em acr 2.
• Valem as mesmas recusas do login por senha: conta suspensa ou inativa, sem acesso ao client, endereço de origem não aprovado.
• Se o client oferece passkeys e a conta não tem nenhuma, a etapa de cadastro é oferecida.
• Os erros do provedor viram uma mensagem fixa no login hospedado, com a marca e o idioma do client; uma pessoa que recusa no provedor é tratada como uma escolha, não como uma falha.

O que a sua aplicação pediu segue até o provedor na medida em que cada um entende:

Papéis a partir das claims do provedor

Um provedor pode conceder papéis. Na aba Acesso do provedor, adicione regras que transformam uma claim enviada pelo provedor — groups contendo financeiro, um departamento, um tenant — num papel do realm. As regras rodam em todo login federado.

Uma claim que chega e não casa sempre retira o papel. As regras só mexem nos papéis concedidos pelas regras do mesmo provedor: papéis dados à mão ou por grupo nunca são retirados. Antes de salvar, a pré-visualização mostra o que uma regra concederia ou retiraria, reproduzindo o último login real de uma pessoa ou claims que você digita.

Como o broker protege o login

• PKCE com S256 em todos os provedores, inclusive os confidenciais, um state opaco de uso único válido por 15 minutos e um nonce conferido no ID token.
• O ID token do provedor é validado por inteiro: assinatura contra as chaves publicadas, emissor, audiência e validade.
• Só os provedores oferecidos no client podem ser usados a partir do login dele, e só enquanto estiverem ativos.
• As chamadas ao provedor, inclusive ao documento de descoberta e às chaves dele, vão só para endereços públicos e nunca seguem redirecionamentos.
• A sua aplicação nunca recebe os tokens do provedor, só um código comum do Authio.

Ocultar e remover um provedor

Ocultar um provedor em Provedores de identidade o deixa inativo: o botão some de todas as telas de login e o broker recusa logins por ele. Mostrar de novo é imediato.

Remover um provedor mantém as contas que chegaram por ele, mas elas perdem esse caminho de entrada. Quem não tem senha precisa de outro meio de entrar, como uma redefinição de senha ou uma passkey.

Próximos passos