Configurar login social com OpenID Connect (OIDC)

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

dica

Neste guia, assumimos que você tem conhecimento básico sobre Conectores (Connectors) do Logto. Se não tiver, confira o guia Configurar conectores para começar.

Introdução

O conector OIDC permite a conexão do Logto a um provedor de identidade social arbitrário que suporta o protocolo OIDC.

ℹ️ Nota

O conector OIDC é um tipo especial de conector no Logto, você pode adicionar alguns conectores baseados em OIDC.

Crie seu aplicativo OIDC

Quando você abre esta página, acreditamos que você já sabe qual provedor de identidade social deseja conectar. A primeira coisa a fazer é confirmar que 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

Nós 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 dos seus aplicativos OIDC.

clientId: O ID do cliente é 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 cliente específico.

clientSecret: O segredo do cliente é 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 segredo do cliente é 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 métodos suportados, consulte o campo token_endpoint_auth_methods_supported disponível no endpoint de descoberta do OpenID Connect do provedor de serviços OAuth 2.0, ou consulte a documentação relevante fornecida pelo provedor de serviços OAuth 2.0.

clientSecretJwtSigningAlgorithm (Opcional): Apenas necessário quando tokenEndpointAuthMethod é client_secret_jwt. O algoritmo de assinatura JWT do segredo do cliente é 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 de escopo é usado para especificar o conjunto de recursos e permissões que o aplicativo cliente está solicitando acesso. O parâmetro de escopo é tipicamente definido como uma lista de valores separados por espaço que representam permissões específicas. Por exemplo, um valor de escopo de "read write" pode indicar que o aplicativo cliente está solicitando acesso de leitura e escrita aos dados de um usuário.

Espera-se que você encontre authorizationEndpoint, tokenEndpoint, jwksUri e issuer como informações de configuração do Provedor OpenID. 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 fazer login e conceder autorização para que o aplicativo cliente acesse 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: Este é o endpoint URL onde o Conjunto de Chaves Web JSON (JWKS) do provedor de identidade social (abreviado como IdP) pode ser obtido. O JWKS é um conjunto de chaves criptográficas que o IdP usa para assinar e verificar JSON Web Tokens (JWTs) que são emitidos durante o processo de autenticação. O jwksUri é usado pela parte confiável (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 a reivindicação iss (o token de ID é sempre um JWT). O valor do emissor deve corresponder ao 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 a reivindicação iss para garantir que foi emitido por um IdP confiável e que o JWT é destinado 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 emissor garante que a RP apenas aceite JWTs que foram emitidos por um IdP confiável e que os JWTs são destinados ao uso com a RP.

Como uma solicitação de autenticação é sempre necessária, um authRequestOptionalConfig é fornecido para encapsular 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 nonce deve ser idêntico para cada solicitação, colocamos a geração de nonce na implementação do código. Então, não se preocupe com isso! O anteriormente mencionado jwksUri e issuer também estão incluídos em idTokenVerificationConfig.

Você pode estar curioso sobre por que um protocolo OIDC padrão suporta tanto os fluxos implícitos quanto híbridos, mas o conector Logto suporta apenas o fluxo de autorização. Foi determinado que os fluxos implícitos e híbridos são menos seguros do que o fluxo de autorização. Devido ao foco do Logto na segurança, ele suporta apenas o fluxo de autorização para o mais alto nível de segurança para seus usuários, apesar de sua natureza ligeiramente menos conveniente.

responseType e grantType podem ser SOMENTE 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 customConfig OPCIONAL para colocar seus parâmetros personalizados. Cada provedor de identidade social pode ter sua própria variante no protocolo padrão OIDC. Se o provedor de identidade social desejado seguir estritamente o protocolo padrão OIDC, então você não precisa se preocupar com customConfig.

Tipos de configuração

Nome	Tipo	Obrigatório
scope	string	True
clientId	string	True
clientSecret	string	True
authorizationEndpoint	string	True
tokenEndpoint	string	True
idTokenVerificationConfig	IdTokenVerificationConfig	True
authRequestOptionalConfig	AuthRequestOptionalConfig	False
customConfig	Record<string, string>	False

Propriedades de AuthRequestOptionalConfig	Tipo	Obrigatório
responseType	string	False
tokenEndpoint	string	False
responseMode	string	False
display	string	False
prompt	string	False
maxAge	string	False
uiLocales	string	False
idTokenHint	string	False
loginHint	string	False
acrValues	string	False

Propriedades de IdTokenVerificationConfig	Tipo	Obrigatório
jwksUri	string	True
issuer	string | string[]	False
audience	string | string[]	False
algorithms	string[]	False
clockTolerance	string | number	False
crit	Record<string, string | boolean>	False
currentDate	Date	False
maxTokenAge	string | number	False
subject	string	False
typ	string	False

Veja aqui para encontrar mais detalhes sobre IdTokenVerificationConfig.