Explora os campos chave 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 websites e aplicações. OpenID Connect (OIDC), uma camada de autenticação construída sobre o protocolo OAuth 2.0, oferece uma forma 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 ficheiro de configuração do OIDC, normalmente encontrado no URL {authServerUrl}/.well-known/openid-configuration, que contém todos os detalhes necessários para implementar serviços OIDC.
Este guia visa esclarecer os principais campos dentro desta configuração, ajudando os desenvolvedores a compreender a sua importância e aplicações práticas para melhor integrar o OIDC nos seus projetos.
A configuração do OIDC é um ficheiro JSON semelhante ao seguinte:
A seguir, vamos aprofundar-nos em alguns dos campos-chave.
Ao integrar serviços OIDC, o primeiro passo geralmente envolve lidar com pedidos de login de utilizadores dentro da aplicação. Este processo inclui redirecionar os utilizadores para o authorization_endpoint do servidor de autorização. Este endpoint é o endereço do servidor onde os pedidos de autorização são enviados, guiando os utilizadores para a página de login para autenticação.
Ao fazer um pedido ao 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. Isto normalmente inclui "code" (para o fluxo de código 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 OIDC.client_id: Um identificador único atribuído à aplicação pelo servidor de autorização quando a app é registada. Este ID é usado pelo servidor de autorização para reconhecer a aplicação cliente que inicia o pedido.scope: Define o âmbito de acesso solicitado, especificando os recursos ou informações dos utilizadores acessíveis. Âmbitos comuns incluem "openid" (obrigatório), "profile" e "email", entre outros. Você pode encontrar os âmbitos suportados no campo scopes_supported da configuração do OIDC; âmbitos diferentes devem ser separados por espaços.redirect_uri: Após o login ou autorização, o servidor de autorização redireciona o utilizador de volta para o URI fornecido pela aplicação. Este URI deve corresponder estritamente ao URI fornecido durante o registo da aplicação.state: Uma string gerada aleatoriamente usada para proteger o cliente de ataques de falsificação de pedidos entre sites (CSRF). A consistência do state entre o pedido de autorização e o callback deve ser mantida para garantir a segurança.Estes parâmetros permitem aos desenvolvedores controlar precisamente o comportamento dos pedidos de autorização do OIDC, garantindo que sejam seguros e atendam às necessidades da aplicação.
Após completar o pedido ao authorization_endpoint e passar pela autenticação, os utilizadores são redirecionados para o redirect_uri especificado, que incluirá um parâmetro de consulta muito crucial—code. Este código de autorização é fornecido pelo servidor de autorização e é o resultado da autenticação do utilizador e da autorização da aplicação para aceder às 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 anteriormente por tokens de acesso e refresh. No fluxo de código de autorização do OAuth 2.0, este passo é crucial, pois envolve converter o código de autorização obtido em tokens de acesso reais, que a aplicação pode usar para aceder aos recursos protegidos do utilizador.
Aqui está como a troca do código de autorização por tokens de acesso é implementada (note 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 mais adiante do campo
token_endpoint_auth_methods_supportedNeste código, primeiro enviamos um pedido ao 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 do pedido inclui os seguintes parâmetros:
redirectUri depois do utilizador completar a autorização.Esta função é executada de forma assíncrona e retorna um objeto JSON contendo o token de acesso, que a aplicação pode usar para solicitar dados do utilizador ou executar outras operações.
userinfo_endpoint é o endpoint do servidor utilizado pelo servidor de autorização para obter informações detalhadas sobre os utilizadores autenticados. Depois dos utilizadores autorizarem e obterem tokens de acesso através do token_endpoint, a aplicação pode solicitar a este endpoint para aceder às informações de perfil do utilizador, como nome de utilizador e endereço de email. As informações específicas obtidas dependem do scope especificado pelo utilizador no pedido de autenticação.
Nesta função, primeiro utilizamos o método GET para solicitar ao userinfo_endpoint, incluindo o campo Authorization no cabeçalho do pedido composto pelo token_type e accessToken. Esta é uma operação padrão de acordo com a especificação OAuth 2.0, assegurando a obtenção segura das informações do utilizador. Adicionalmente, o âmbito das informações de utilizador acessadas através do token de acesso depende completamente dos valores dos parâmetros scope adotados pelo utilizador durante a iniciação da autorização. Por exemplo, se o âmbito email for utilizado, a resposta deve incluir o endereço de email do utilizador.
O issuer 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 de JWT. Verificar o issuer e a assinatura do JWT são passos básicos para garantir a segurança do token, mas em cenários reais, o processo de verificação geralmente inclui também verificar o período de validade do token, a audiência, o âmbito de autorização e outros campos importantes.
O código seguinte demonstra principalmente como usar o issuer e jwks_uri juntos para verificar um JWT:
Os campos claims_supported e scopes_supported declaram os atributos do utilizador (claims) e os âmbitos de acesso (scopes) suportados pelo servidor de autorização. Estes ajudam os clientes a entender quais atributos do utilizador e âmbitos de acesso são suportados pelo servidor de autorização, permitindo que os clientes construam eficazmente os pedidos de autorização e analisem as respostas.
Ao construir um pedido de autorização, os clientes podem especificar o scope necessário com base nas necessidades da aplicação. Scope define os recursos e operações aos quais o cliente solicita acesso, como openid, email, profile, entre outros.
É importante notar que os claims específicos acessíveis em cada pedido de autorização variam com base nos valores do scope especificados no início do pedido de autenticação. Por exemplo, o âmbito email concede acesso ao endereço de email do utilizador, enquanto o âmbito phone fornece acesso ao seu número de telefone. Portanto, os clientes devem escolher cuidadosamente o scope relevante para corresponder às necessidades da aplicação ao elaborar um pedido de autorização, assegurando que possam obter os atributos de utilizador necessários:
O campo
token_endpoint_auth_methods_supportedAo autenticar-se 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 o seu identificador de cliente e segredo do cliente para construir um corpo de formulário codificado, que é enviado como parte do corpo do pedido. Já vimos um exemplo deste método na seção token_endpoint acima.
client_secret_basic: O cliente usa o seu identificador de cliente e segredo do cliente para construir um cabeçalho de autenticação básica, que é adicionado ao cabeçalho do pedido.
client_secret_jwt: O cliente usa um JWT (JSON Web Token) como uma asserção do cliente para autenticar. Este JWT contém o identificador do cliente e alguns metadados adicionais e é assinado usando o segredo do cliente. Após receber o pedido, o servidor de autorização verifica a identidade do cliente validando a assinatura 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 ao pedido para trocar de forma segura o código de autorização por tokens de acesso.
Já explorámos os campos-chave na configuração OIDC, focando nos seus propósitos e aplicações. Compreender estes detalhes irá melhorar o seu entendimento do OpenID Connect, capacitando-o a integrá-lo e utilizá-lo mais eficazmente nos seus projetos. Armado com este conhecimento, você está melhor preparado para aproveitar todo o potencial do OIDC para soluções de autenticação de utilizadores mais seguras e eficientes.
O Logto, um serviço de autenticação construído sobre o OIDC, que oferece um conjunto abrangente de SDKs em várias linguagens juntamente com inúmeros tutoriais de integração, permite-lhe integrar logins OAuth / OIDC nas suas aplicações em apenas alguns minutos. Se está à procura de um serviço OIDC confiável e fácil de usar, experimente o Logto hoje!