O OpenID Connect (OIDC) é uma camada de identidade construída sobre o OAuth 2.0, que permite a autenticação dos usuários e obter as informações do perfil deles nos aplicativos. O OAuth 2.0 cuida da autorização (o que um usuário pode acessar), enquanto o OIDC adiciona a autenticação (quem o usuário é) utilizando tokens de ID padronizados.

Exemplo: ao clicar em “Continuar com o Google”, para iniciar sessão no Spotify, o OIDC verifica sua identidade com o Google. O Spotify recebe suas informações de perfil, como nome e endereço de e-mail. Sua senha do Google nunca é compartilhada. O Google emite um token de ID que contém declarações de identidade, como seu ID de usuário e informações de perfil. Algumas declarações (como a verificação de e-mail) são marcadas explicitamente como verificadas.

O OIDC foi amplamente adotado para autenticação moderna na web e em dispositivos móveis. Publicado em 2014 pela OpenID Foundation, ele combina a autorização OAuth 2.0 com a verificação de identidade. Os principais provedores de identidade aceitam o OIDC, o que faz com que ele seja amplamente usado para Single Sign-On (SSO), login social e aplicações voltadas para o consumidor.

Antes do OIDC, os desenvolvedores enfrentavam três desafios principais:

1. Ausência de uma camada de identidade padrão

   O OAuth 2.0 fornece autorização, mas não define um método de autenticação padronizado ou interoperável. Como resultado, os desenvolvedores criavam soluções personalizadas, o que causava problemas de interoperabilidade.

2. Alternativas complexas

   O SAML 2.0 é compatível com a autenticação corporativa, mas utiliza XML detalhado, requer certificados e apresenta desempenho insatisfatório em dispositivos móveis.

3. Riscos de exposição de credenciais

   No passado, as aplicações costumavam armazenar credenciais de usuário ou exigiam o compartilhamento de senhas, o que criava riscos de segurança e uma experiência de usuário inferior.

O OIDC resolve esses problemas. As aplicações recebem tokens de identificação assinados criptograficamente com declarações de identidade comprovadas. O armazenamento de credenciais não é mais necessário, e a autenticação é consistente em todas as plataformas. O OIDC autentica usuários, mas não gerencia dados, funções ou permissões específicas da aplicação.

O OIDC se baseia nas funções e na terminologia específica de identidade do OAuth 2.0:

• Usuário final: a pessoa cuja identidade está sendo verificada.
• Parte confiante (RP): a aplicação que solicita a autenticação do usuário.
• Provedor OpenID (OP): o provedor de identidade que autentica usuários e emite tokens de ID. No OIDC, o OP funciona como o servidor de autorização OAuth 2.0.

Declarações de tokens de ID

Os tokens de ID são JSON Web Tokens (JWTs) que contêm declarações de identidade e devem ser validados antes do uso:

• sub: identificador estável e exclusivo para o usuário dentro do emissor
• iss: emissor do token (URL do provedor OpenID)
  aud: aplicação pretendida (ID do cliente)
• exp: tempo de expiração (registro de data e hora Unix)
• iat: emitido às (registro de data e hora Unix)
• auth_time: registro de data e hora da autenticação
• nonce: impede ataques de repetição (obrigatório se enviado na requisição)

Escopos comuns do OIDC

Os escopos definem as informações do usuário solicitadas:

• openid: obrigatório; aciona o OIDC
• profile: nome, foto e informações básicas do perfil
• email: endereço de e-mail e verificação
• address: endereço físico
• phone: número de telefone e verificação

Como o OIDC é uma extensão do OAuth 2.0, o fluxo é semelhante ao fluxo de código de autorização do OAuth, com adições específicas do OIDC.

O fluxo de autenticação do OIDC

1. Solicitação de autenticação: a RP redireciona o usuário para o OP com ID do cliente, URI de redirecionamento, response_type=code e escopo, incluindo openid.
2. Autenticação e consentimento do usuário: o OP autentica o usuário com uma senha, MFA ou biometria. A tela de consentimento exibe os dados solicitados.
3. Resposta de autorização: o OP redireciona de volta com um código de autorização e um parâmetro de estado.
   Solicitação de token: a RP troca um código por três tokens: um token de ID, um token de acesso e um token de atualização (opcional). Clientes confidenciais fazem isso de servidor para servidor. Clientes públicos usam PKCE.
4. Validação de token: a RP valida a assinatura, a expiração, o emissor, o público-alvo e o nonce do token de ID usando as chaves públicas do provedor (JWKS). O token de ID é exclusivo para a aplicação cliente e nunca deve ser enviado para APIs. As APIs devem validar os tokens de acesso.
5. Acesso ao perfil do usuário: opcionalmente, a RP chama o endpoint UserInfo com um token de acesso para recuperar declarações adicionais do perfil.

Proof Key for Code Exchange (PKCE)

O PKCE previne ataques de interceptação de código de autorização. Clientes públicos (apps móveis e SPAs) usam o PKCE porque não conseguem armazenar segredos do cliente com segurança. Clientes confidenciais geralmente se autenticam com um segredo do cliente. Muitas implantações modernas também adicionam o PKCE para defesa em profundidade.

Para determinar qual fluxo usar:

Fluxo	Caso de uso	Segurança	Status
Código de autorização com PKCE	Todos os apps modernos (web, móveis, SPAs)	Mais alta	Recomendado para todos os clientes
Fluxo implícito	Nenhum	Baixa	Obsoleto (RFC 8252)
Fluxo híbrido	Empresa complexa	Média	Somente legado

• O código de autorização com PKCE é a prática recomendada e espera-se que seja obrigatório no OAuth 2.1.
• O fluxo implícito está obsoleto devido a vulnerabilidades de segurança.
• O fluxo híbrido é usado principalmente em cenários empresariais legados ou especializados e geralmente é desnecessário para a maioria das aplicações modernas.

Validação dos tokens de ID

Nos tokens de ID, é preciso validar assinatura, expiração, emissor, público-alvo e nonce.

Etapas da validação:

• Verificar a assinatura usando chaves JWKS
• Verificar se o emissor corresponde ao provedor
• Verificar se o público-alvo corresponde ao ID do cliente
• Confirmar se o token não expiro
• Validar se o nonce corresponde à solicitação

Boa prática: utilize bibliotecas já estabelecidas do OIDC que façam a validação.

Como lidar com o nonce

O nonce previne ataques de repetição. Sem ele, um invasor poderia reproduzir um token de ID válido. Nonces previsíveis, reutilizados ou não verificados não são seguros.

Boa prática: gere nonces criptograficamente aleatórios, armazene-os no servidor com um TTL (5 a 10 minutos) e valide as correspondências exatas.

Armazenamento de token

Os tokens de ID contêm informações sensíveis. Nunca use localStorage ou sessionStorage devido a vulnerabilidades de cross-site scripting (XSS).

Boa prática: utilize armazenamento em memória para SPAs ou cookies seguros HTTP-only ao usar o padrão backend-for-frontend (BFF). Sessões criptografadas no servidor são mais seguras.

Solicitações de escopo

Solicite apenas os escopos de que o app precisa. Evite dados de perfil desnecessários.

Uso do endpoint UserInfo

Chame o UserInfo apenas se o token de ID não contiver as declarações necessárias. O endpoint requer um token de acesso e geralmente possui limite de taxa. Sempre valide os tokens de acesso e armazene as respostas em cache conforme necessário.

O OIDC funciona melhor para aplicações voltadas para o consumidor, apps móveis e autenticação web moderna. Escolha OIDC para login social, SSO e cenários em que os usuários se autenticam com contas existentes.

O SAML 2.0 continua sendo comum em sistemas legados de empresas e governos, enquanto muitas organizações adotam cada vez mais o OIDC para novas aplicações voltadas à força de trabalho. Muitas organizações usam ambos: OIDC para apps modernos e SAML para Enterprise Federation.

• Valide os tokens de ID por completo usando chaves JWKS. Verifique a assinatura, exp, iss, aud e nonce. (Os tokens de ID nunca devem ser enviados para APIs.)
• Utilize HTTPS para todas as comunicações de produção. O RFC 6749 permite exceções de localhost apenas para desenvolvimento.
• Implemente PKCE para todos os clientes. (Espera-se que seja obrigatório no OAuth 2.1)
• Armazenamento seguro de tokens com cookies HTTP-only ou sessões no lado do servidor.
• Valide os URIs de redirecionamento explicitamente. Nunca use curingas.
• Implemente o parâmetro de estado para prevenir ataques CSRF.
• Use tokens de curta duração (15 a 60 minutos) e tokens de atualização com rotação.
• Respeite o consentimento do usuário e minimize os dados de perfil solicitados.

Aspecto	OIDC	OAuth 2.0	SAML 2.0
Finalidade	Autenticação	Autorização	Autenticação e SSO
Desenvolvido em	OAuth 2.0	Especificações OAuth da IETF	Padrões SAML baseados em XML
Formato do token	JWT	Token de portador (formato não especificado)	XML
Declarações de identidade	Padronizadas	Não definidas	Declarações de atributos
Suporte móvel	Excelente	Excelente	Ruim
Casos de uso	Autenticação de usuário, login social	Acesso à API	SSO corporativo
Complexidade	Baixa	Baixa	Alta
Público-alvo	Apps modernos	APIs	Enterprise Federation

O OIDC e o OAuth 2.0 se complementam. O OIDC responde à pergunta “Quem é este usuário?”. O OAuth 2.0 responde à pergunta “Quais recursos este usuário pode acessar?”. O SAML é amplamente utilizado para SSO empresarial. O OIDC é o método preferido para apps modernos e suporte a dispositivos móveis.

Qual é a diferença entre o OAuth 2.0 e o OpenID Connect?

O OAuth 2.0 é para autorização. O OIDC adiciona a autenticação. O OAuth responde à pergunta: “O que este app pode acessar?” O OIDC responde à pergunta “Quem é este usuário?”.

O que é um token de ID e por que ele é importante?

Um token de ID é um JWT assinado que contém declarações de identidade feitas pelo provedor. Ele comprova que a autenticação ocorreu. Ao contrário dos tokens de acesso, sua função é permitir que o cliente verifique a identidade de um usuário. A assinatura permite a validação sem a necessidade de contato com o fornecedor. As declarações mais comuns incluem o ID do usuário (sub), o e-mail e o horário de autenticação. Valide sempre os tokens de ID.

Posso usar o OIDC sem o OAuth 2.0?

Não. O OIDC é baseado no OAuth 2.0. Cada fluxo do OIDC é um fluxo do OAuth 2.0 com o escopo openid e o token de ID adicionados. O OIDC estende o OAuth 2.0, mas não o substitui.

O OIDC é mais seguro que o SAML?

Ambos são seguros se implementados corretamente. O OIDC utiliza uma validação JWT mais simples. O SAML requer assinaturas XML, que apresentam maior complexidade. A maioria das vulnerabilidades surge de erros de implementação, não do protocolo em si. O formato de token mais simples do OIDC ajuda a reduzir o risco de implementação.

O que é o endpoint UserInfo?

O endpoint UserInfo retorna declarações adicionais do perfil do usuário. Ele exige um token de acesso válido, não o token de ID. Utilize-o somente se o token de ID não contiver as declarações necessárias. O endpoint geralmente está sujeito a limite de taxa, por isso, é recomendado implementar cache para melhorar o desempenho.

Preciso validar os tokens de ID de um provedor confiável?

Sim. Sempre valide a assinatura, o emissor, o público-alvo, a data de expiração e o nonce. A validação garante que o token seja genuíno, atual e destinado à sua aplicação. Mesmo os tokens de fornecedores confiáveis devem ser validados para evitar adulteração e ataques de repetição.

O OIDC pode funcionar sem HTTPS?

Não. O HTTPS é obrigatório para produção. Os invasores podem interceptar tokens enviados via HTTP. Exceções para localhost são permitidas apenas para fins de desenvolvimento.

Como usar as bibliotecas do OIDC

Bibliotecas consolidadas lidam com validação de tokens, gerenciamento de chaves JWKS e detalhes do protocolo. As bibliotecas podem ajudar a reduzir erros, mas exigem uma compreensão dos conceitos do OIDC.

As bibliotecas populares de código aberto incluem:

• Node.js: openid-client
• Python: authlib
• Python: pyoidc
• Java: Spring Security OAuth

Como usar plataformas de identidade

As plataformas de identidade oferecem implementações de OIDC e OAuth 2.0 com recursos integrados de segurança, login social e tradução de protocolos. Elas também podem gerenciar atualizações, conformidade e escalabilidade, permitindo que os desenvolvedores se concentrem na lógica da aplicação

A Auth0 simplifica as implementações de OIDC e OAuth 2.0, permitindo que os desenvolvedores se concentrem na criação de aplicações enquanto lidam com a autenticação e a identidade de forma segura.

Confira nossa série "Introdução ao IAM" sobre gerenciamento de identidade e acesso.

Saiba mais

Este material destina-se apenas a fins informativos gerais. Você é responsável por obter aconselhamento sobre segurança, privacidade, conformidade ou negócios de seus próprios consultores profissionais e não deve confiar exclusivamente nas informações aqui fornecidas.