Explora os campos principais e aplicações práticas da configuração do OpenID Connect.
No mundo digital de hoje, a autenticação tornou-se um componente central para a segurança de sites e aplicativos. OpenID Connect (OIDC), uma camada de autenticação construída sobre o protocolo OAuth 2.0, oferece uma maneira padronizada e simples de autenticar identidades.
No entanto, integrar corretamente o OIDC pode ser assustador, especialmente para iniciantes. Um bom ponto de partida geralmente é o arquivo de configuração do OIDC, normalmente encontrado na URL {authServerUrl}/.well-known/openid-configuration, que contém todos os detalhes necessários para implementar serviços OIDC.
Este guia tem como objetivo esclarecer os campos principais dentro dessa configuração, ajudando os desenvolvedores a compreender sua importância e aplicações práticas para integrar melhor o OIDC em seus projetos.
A configuração do OIDC é um arquivo JSON semelhante ao seguinte:
Em seguida, vamos nos aprofundar em alguns dos campos principais.
Ao integrar serviços OIDC, o primeiro passo geralmente envolve lidar com as solicitações de login do usuário dentro do aplicativo. Esse processo inclui redirecionar os usuários para o authorization_endpoint do servidor de autorização. Este endpoint é o endereço do servidor onde as solicitações de autorização são enviadas, guiando os usuários para a página de login para autenticação.
Ao fazer uma solicitação para o authorization_endpoint, ele deve ser configurado com parâmetros de consulta adicionais para cada autorização:
response_type: Especifica o tipo de autorização retornada. Isso geralmente inclui "code" (para o fluxo de autorização), "token" (para o fluxo implícito) e "id_token token" ou "code id_token" (para o fluxo híbrido), que podem ser encontrados no campo response_types_supported da configuração do OIDC.client_id: Um identificador exclusivo atribuído ao aplicativo pelo servidor de autorização quando o aplicativo é registrado. Este ID é usado pelo servidor de autorização para reconhecer o aplicativo cliente que está iniciando a solicitação.scope: Define o escopo de acesso solicitado, especificando os recursos ou informações do usuário acessíveis. Escopos comuns incluem "openid" (obrigatório), "profile" e "email", entre outros. Você pode encontrar os escopos suportados no campo scopes_supported da configuração do OIDC; escopos diferentes devem ser separados por espaços.redirect_uri: Após o login ou autorização, o servidor de autorização redireciona o usuário de volta para o URI fornecido pelo aplicativo. Este URI deve corresponder estritamente ao URI fornecido durante o registro do aplicativo.state: Uma string gerada aleatoriamente usada para proteger o cliente contra ataques de falsificação de solicitação entre sites (CSRF). A consistência do estado entre a solicitação de autorização e o callback deve ser mantida para garantir a segurança.Esses parâmetros permitem que os desenvolvedores controlem precisamente o comportamento das solicitações de autorização OIDC, garantindo que sejam seguras e atendam às necessidades do aplicativo.
Após concluir a solicitação para o authorization_endpoint e passar pela autenticação, os usuários são redirecionados para o redirect_uri especificado, que incluirá um parâmetro de consulta muito importante—code. Este código de autorização é fornecido pelo servidor de autorização e é o resultado de o usuário autenticar e autorizar o aplicativo a acessar suas informações no servidor de autorização.
token_endpoint é o endpoint do servidor usado pelo servidor de autorização para trocar o código de autorização mencionado acima por tokens de acesso e refresh tokens. No fluxo de código de autorização do OAuth 2.0, esta etapa é crucial, pois envolve converter o código de autorização obtido em tokens de acesso reais, que o aplicativo pode usar para acessar os recursos protegidos do usuário.
Aqui está como a troca do código de autorização por tokens de acesso é implementada (observe que este exemplo usa o método de autenticação client_secret_post. Para outros métodos de autenticação suportados, consulte a análise posterior do campo
token_endpoint_auth_methods_supportedNeste código, primeiro enviamos uma solicitação para o token_endpoint usando o método POST. O tipo de conteúdo é definido como application/x-www-form-urlencoded, que é exigido pela maioria dos servidores de autorização. O corpo da solicitação inclui os seguintes parâmetros:
redirectUri após o usuário concluir a autorização."authorization_code" aqui, que indica que o token de acesso é obtido por meio do código de autorização.Essa função é executada de forma assíncrona e retorna um objeto JSON contendo o token de acesso, que o aplicativo pode usar para solicitar dados do usuário ou realizar outras operações.
userinfo_endpoint é o endpoint do servidor usado pelo servidor de autorização para obter informações detalhadas sobre usuários autenticados. Depois que os usuários autorizam com sucesso e obtêm tokens de acesso através do token_endpoint, o aplicativo pode solicitar este endpoint para acessar as informações do perfil do usuário, como nome de usuário e endereço de e-mail. As informações específicas obtidas dependem do scope especificado pelo usuário na solicitação de autenticação.
Nesta função, primeiro usamos o método GET para solicitar o userinfo_endpoint, incluindo o campo Authorization no cabeçalho da solicitação composto pelo token_type e accessToken. Esta é uma operação padrão de acordo com a especificação OAuth 2.0, garantindo a recuperação segura das informações do usuário. Além disso, o escopo das informações do usuário acessadas através do token de acesso depende completamente dos valores dos parâmetros scope adotados pelo usuário durante a iniciação da autorização. Por exemplo, se o escopo email for usado, a resposta deve incluir o endereço de e-mail do usuário.
O emissor identifica a URL do servidor de autorização, enquanto o jwks_uri fornece o URI para o JSON Web Key Set (JWKS), que é um conjunto de chaves públicas usadas para verificar assinaturas JWT. Verificar o issuer e a assinatura do JWT são etapas básicas para garantir a segurança do token, mas em cenários reais
o processo de verificação geralmente também inclui verificar o período de validade do token, o público, o escopo de autorização e outros campos importantes.
O código a seguir demonstra principalmente como usar o issuer e o jwks_uri juntos para verificar um JWT:
Os campos claims_supported e scopes_supported declaram os atributos do usuário (claims) e os escopos de acesso (scopes) suportados pelo servidor de autorização. Eles ajudam os clientes a entender quais atributos de usuário e escopos de acesso são suportados pelo servidor de autorização, permitindo que os clientes construam efetivamente solicitações de autorização e analisem respostas.
Ao construir uma solicitação de autorização, os clientes podem especificar o scope necessário com base nas necessidades do aplicativo. Scope define os recursos e operações que o cliente solicita acesso, como openid, email, profile, e outros.
É importante notar que as claims específicas acessíveis em cada solicitação de autorização variam com base nos valores de escopo especificados no início da solicitação de autenticação. Por exemplo, o escopo de email concede acesso ao endereço de e-mail do usuário, enquanto o escopo de phone fornece acesso ao número de telefone. Portanto, os clientes devem escolher cuidadosamente o escopo relevante para corresponder às necessidades do aplicativo ao criar uma solicitação de autorização, garantindo que possam recuperar os atributos do usuário necessários:
O campo
token_endpoint_auth_methods_supportedAo autenticar usando o token endpoint, métodos de autenticação comuns incluem client_secret_post, client_secret_basic e client_secret_jwt.
client_secret_post: O cliente usa seu identificador de cliente e segredo de cliente para construir um corpo codificado em formulário, que é enviado como parte do corpo da solicitação. Já vimos um exemplo deste método na seção token_endpoint acima.
client_secret_basic: O cliente usa seu identificador de cliente e segredo de cliente para construir um cabeçalho de autenticação básica, que é adicionado ao cabeçalho da solicitação.
client_secret_jwt: O cliente usa um JWT (JSON Web Token) como uma afirmação de cliente para se autenticar. Esse JWT contém o identificador do cliente e alguns metadados adicionais e é assinado usando o segredo do cliente. Após receber a solicitação, o servidor de autorização verifica a identidade do cliente validando a assinatura do JWT.Em aplicações práticas, os clientes precisam selecionar o método de autenticação apropriado com base nos métodos suportados pelo servidor de autorização, e garantir que as informações de autenticação sejam corretamente adicionadas à solicitação para trocar com segurança o código de autorização por tokens de acesso.
Agora exploramos os campos principais na configuração do OIDC, concentrando-nos em seus propósitos e aplicações. Compreender esses detalhes aprimorará sua compreensão do OpenID Connect, capacitando-o a integrá-lo e utilizá-lo de maneira mais eficaz em seus projetos. Com esse conhecimento, você estará melhor preparado para aproveitar todo o potencial do OIDC para soluções de autenticação de usuários mais seguras e eficientes.
O Logto como um serviço de autenticação baseado em OIDC, que oferece um conjunto abrangente de SDKs em várias linguagens, juntamente com inúmeros tutoriais de integração, permite que você integre logins OAuth / OIDC aos seus aplicativos em apenas alguns minutos. Se você está procurando um serviço OIDC confiável e fácil de usar, experimente o Logto hoje!