Pular para o conteúdo principal

Configurar login social com OpenID Connect (OIDC) (Set up social login with OpenID Connect (OIDC))

O conector oficial do Logto para o protocolo OpenID Connect (OIDC).

dica:

Este guia assume que você tem um entendimento básico dos Conectores (Connectors) do Logto. Para aqueles que não estão familiarizados, consulte o guia de Conectores para começar.

Primeiros passos

O conector OIDC permite a conexão do Logto a qualquer provedor de identidade social que suporte o protocolo OIDC. Use o conector OIDC para permitir que seu aplicativo:

  • Adicione botões de login social
  • Vincule contas de usuário a identidades sociais
  • Sincronize informações do perfil do usuário a partir do provedor social
  • Acesse APIs de terceiros por meio do armazenamento seguro de tokens no Logto Secret Vault para tarefas de automação (por exemplo, editar Google Docs, gerenciar eventos do Calendar em seu app)

Para configurar esses recursos de autenticação, crie primeiro um conector OIDC no Logto:

  1. Acesse Console do Logto > Conector > Conector social.
  2. Clique em Adicionar conector social, selecione OIDC, clique em Próximo e siga o tutorial passo a passo para concluir a integração.
nota:

O conector OIDC é um tipo especial de conector no Logto, você pode adicionar vários conectores baseados no protocolo OIDC.

Crie seu aplicativo OIDC

Ao abrir esta página, acreditamos que você já sabe qual provedor de identidade social deseja conectar. A primeira coisa a fazer é confirmar se o provedor de identidade suporta o protocolo OIDC, que é um pré-requisito para configurar um conector válido. Em seguida, siga as instruções do provedor de identidade para registrar e criar o aplicativo relevante para autorização OIDC.

Configure seu conector

SOMENTE suportamos o tipo de concessão "Authorization Code" por questões de segurança e ele se encaixa perfeitamente no cenário do Logto.

clientId e clientSecret podem ser encontrados na página de detalhes do seu aplicativo OIDC.

clientId: O client ID é um identificador único que identifica o aplicativo cliente durante o registro com o servidor de autorização. Este ID é usado pelo servidor de autorização para verificar a identidade do aplicativo cliente e associar quaisquer tokens de acesso autorizados a esse aplicativo específico.

clientSecret: O client secret é uma chave confidencial emitida para o aplicativo cliente pelo servidor de autorização durante o registro. O aplicativo cliente usa essa chave secreta para se autenticar com o servidor de autorização ao solicitar tokens de acesso. O client secret é considerado informação confidencial e deve ser mantido seguro o tempo todo.

tokenEndpointAuthMethod: O método de autenticação do endpoint de token é usado pelo aplicativo cliente para se autenticar com o servidor de autorização ao solicitar tokens de acesso. Para descobrir os métodos suportados, consulte o campo token_endpoint_auth_methods_supported disponível no endpoint de descoberta OpenID Connect do provedor de serviço OAuth 2.0, ou consulte a documentação relevante fornecida pelo provedor de serviço OAuth 2.0.

clientSecretJwtSigningAlgorithm (Opcional): Só é necessário quando tokenEndpointAuthMethod é client_secret_jwt. O algoritmo de assinatura JWT do client secret é usado pelo aplicativo cliente para assinar o JWT que é enviado ao servidor de autorização durante a solicitação de token.

scope: O parâmetro scope é usado para especificar o conjunto de recursos e permissões que o aplicativo cliente está solicitando acesso. O parâmetro scope é normalmente definido como uma lista de valores separados por espaço que representam permissões específicas. Por exemplo, um valor de escopo "read write" pode indicar que o aplicativo cliente está solicitando acesso de leitura e escrita aos dados de um usuário.

Você deve encontrar authorizationEndpoint, tokenEndpoint, jwksUri e issuer como informações de configuração do OpenID Provider. Eles devem estar disponíveis na documentação do fornecedor social.

authenticationEndpoint: Este endpoint é usado para iniciar o processo de autenticação. O processo de autenticação normalmente envolve o usuário fazendo login e concedendo autorização para o aplicativo cliente acessar seus recursos.

tokenEndpoint: Este endpoint é usado pelo aplicativo cliente para obter um token de ID que pode ser usado para acessar os recursos solicitados. O aplicativo cliente normalmente envia uma solicitação ao endpoint de token com um tipo de concessão e código de autorização para receber um token de ID.

jwksUri: Esta é a URL do endpoint onde o JSON Web Key Set (JWKS) do provedor de identidade social (IdP) pode ser obtido. O JWKS é um conjunto de chaves criptográficas que o IdP usa para assinar e verificar JSON Web Tokens (JWTs) emitidos durante o processo de autenticação. O jwksUri é usado pela relying party (RP) para obter as chaves públicas usadas pelo IdP para assinar os JWTs, para que a RP possa verificar a autenticidade e integridade dos JWTs recebidos do IdP.

issuer: Este é o identificador único do IdP que é usado pela RP para verificar os JWTs recebidos do IdP. Ele é incluído nos JWTs como o claim iss (o token de ID é sempre um JWT). O valor do issuer deve corresponder à URL do servidor de autorização do IdP, e deve ser um URI que a RP confia. Quando a RP recebe um JWT, ela verifica o claim iss para garantir que foi emitido por um IdP confiável e que o JWT se destina ao uso com a RP.

Juntos, jwksUri e issuer fornecem um mecanismo seguro para a RP verificar a identidade do usuário final durante o processo de autenticação. Usando as chaves públicas obtidas do jwksUri, a RP pode verificar a autenticidade e integridade dos JWTs emitidos pelo IdP. O valor do issuer garante que a RP só aceite JWTs emitidos por um IdP confiável e que os JWTs se destinam ao uso com a RP.

Como uma solicitação de autenticação é sempre necessária, um authRequestOptionalConfig é fornecido para agrupar todas as configurações opcionais. Você pode encontrar detalhes em OIDC Authentication Request. Você também pode notar que nonce está ausente nesta configuração. Como o nonce deve ser idêntico para cada solicitação, colocamos a geração do nonce na implementação do código. Portanto, não se preocupe com isso! Os já mencionados jwksUri e issuer também estão incluídos em idTokenVerificationConfig.

Você pode estar curioso sobre o motivo de um protocolo OIDC padrão suportar tanto os fluxos implícito quanto híbrido, mas o conector Logto suporta apenas o fluxo de autorização. Foi determinado que os fluxos implícito e híbrido são menos seguros do que o fluxo de autorização. Devido ao foco do Logto em segurança, ele suporta apenas o fluxo de autorização para garantir o mais alto nível de segurança para seus usuários, apesar de ser um pouco menos conveniente.

responseType e grantType só podem ser valores FIXOS com o fluxo "Authorization Code", então os tornamos opcionais e os valores padrão serão preenchidos automaticamente.

nota:

Para todos os tipos de fluxo, fornecemos uma chave OPCIONAL customConfig para colocar seus parâmetros personalizados. Cada provedor de identidade social pode ter sua própria variação no protocolo padrão OIDC. Se o seu provedor de identidade social desejado seguir estritamente o protocolo padrão OIDC, então você não precisa se preocupar com o customConfig.

Tipos de configuração

NomeTipoObrigatório
scopestringSim
clientIdstringSim
clientSecretstringSim
authorizationEndpointstringSim
tokenEndpointstringSim
idTokenVerificationConfigIdTokenVerificationConfigSim
authRequestOptionalConfigAuthRequestOptionalConfigNão
customConfigRecord<string, string>Não
Propriedades de AuthRequestOptionalConfigTipoObrigatório
responseTypestringNão
tokenEndpointstringNão
responseModestringNão
displaystringNão
promptstringNão
maxAgestringNão
uiLocalesstringNão
idTokenHintstringNão
loginHintstringNão
acrValuesstringNão
Propriedades de IdTokenVerificationConfigTipoObrigatório
jwksUristringSim
issuerstring | string[]Não
audiencestring | string[]Não
algorithmsstring[]Não
clockTolerancestring | numberNão
critRecord<string, string | boolean>Não
currentDateDateNão
maxTokenAgestring | numberNão
subjectstringNão
typstringNão

Veja aqui para mais detalhes sobre IdTokenVerificationConfig.

Configurações gerais

Aqui estão algumas configurações gerais que não bloqueiam a conexão com seu provedor de identidade, mas podem afetar a experiência de autenticação do usuário final.

Se você quiser exibir um botão social em sua página de login, pode definir o nome e o logo (modo escuro e modo claro) do provedor de identidade social. Isso ajudará os usuários a reconhecerem a opção de login social.

Nome do provedor de identidade

Cada conector social tem um nome único de Provedor de Identidade (IdP) para diferenciar as identidades dos usuários. Enquanto conectores comuns usam um nome de IdP fixo, conectores personalizados exigem um valor único. Saiba mais sobre nomes de IdP para mais detalhes.

Sincronizar informações de perfil

No conector OIDC, você pode definir a política para sincronizar informações de perfil, como nomes de usuário e avatares. Escolha entre:

  • Sincronizar apenas no cadastro: As informações do perfil são buscadas uma vez quando o usuário faz login pela primeira vez.
  • Sempre sincronizar no login: As informações do perfil são atualizadas toda vez que o usuário faz login.

Armazenar tokens para acessar APIs de terceiros (Opcional)

Se você deseja acessar as APIs do Provedor de Identidade e realizar ações com autorização do usuário (seja via login social ou vinculação de conta), o Logto precisa obter escopos de API específicos e armazenar tokens.

  1. Adicione os escopos necessários no campo scope seguindo as instruções acima
  2. Ative Armazenar tokens para acesso persistente à API no conector OIDC do Logto. O Logto armazenará com segurança os tokens de acesso no Cofre de Segredos.
  3. Para provedores de identidade OAuth/OIDC padrão, o escopo offline_access deve ser incluído para obter um token de atualização, evitando solicitações repetidas de consentimento do usuário.
atenção:

Mantenha seu client secret seguro e nunca o exponha em código do lado do cliente. Se for comprometido, gere um novo imediatamente nas configurações do aplicativo do seu provedor de identidade.

Utilize o conector OIDC

Depois de criar um conector OIDC e conectá-lo ao seu provedor de identidade, você pode incorporá-lo aos seus fluxos de usuário final. Escolha as opções que correspondem às suas necessidades:

Habilitar botão de login social

  1. No Logto Console, vá para Experiência de login > Cadastro e login.
  2. Adicione o conector OIDC na seção Login social para permitir que os usuários se autentiquem com seu provedor de identidade.

Saiba mais sobre experiência de login social.

Use a Account API para construir um Centro de Conta personalizado em seu aplicativo que permita aos usuários autenticados vincular ou desvincular suas contas sociais. Siga o tutorial da Account API

dica:

É permitido habilitar o conector OIDC apenas para vinculação de conta e acesso à API, sem habilitá-lo para login social.

Acessar APIs do provedor de identidade e realizar ações

Seu aplicativo pode recuperar tokens de acesso armazenados no Cofre de Segredos para chamar as APIs do seu provedor de identidade e automatizar tarefas de backend. As capacidades específicas dependem do seu provedor de identidade e dos escopos solicitados. Consulte o guia sobre como recuperar tokens armazenados para acesso à API.

Gerenciar a identidade social do usuário

Depois que um usuário vincula sua conta social, os administradores podem gerenciar essa conexão no Logto Console:

  1. Navegue até Logto console > Gerenciamento de usuários e abra o perfil do usuário.
  2. Em Conexões sociais, localize o item do provedor de identidade e clique em Gerenciar.
  3. Nesta página, os administradores podem gerenciar a conexão social do usuário, ver todas as informações de perfil concedidas e sincronizadas da conta social e verificar o status do token de acesso.
nota:

Algumas respostas de token de acesso do Provedor de Identidade não incluem informações específicas de escopo, então o Logto não pode exibir diretamente a lista de permissões concedidas pelo usuário. No entanto, desde que o usuário tenha consentido com os escopos solicitados durante a autorização, seu aplicativo terá as permissões correspondentes ao acessar a API OIDC.