OIDC: o que é e qual o seu papel na autenticação e autorização

Para um gerente de infraestrutura que está começando a trabalhar com gestão de identidades, é comum encontrar uma série de termos que parecem semelhantes: IAM, SSO, OAuth 2.0, OpenID Connect, SAML, access token, ID token, Identity Provider. Essa terminologia pode causar a impressão de que estamos falando de tecnologias concorrentes ou intercambiáveis. Não estamos — cada uma resolve uma parte diferente do problema.

Entre esses conceitos, o OpenID Connect (OIDC) merece atenção especial porque se tornou um dos principais padrões utilizados para permitir que aplicações deleguem a autenticação de usuários para um provedor central de identidade.

Em uma arquitetura moderna, o OIDC é a "linguagem" que permite a uma aplicação perguntar a um provedor de identidade: "esse usuário está autenticado e quem é ele?" O OAuth 2.0, ao mesmo tempo, permite que a aplicação obtenha um access token para acessar recursos protegidos em nome do usuário.

O OpenID Connect é um padrão da OpenID Foundation construído sobre o framework OAuth 2.0. Ele acrescenta justamente a camada padronizada de autenticação e informação sobre a identidade do usuário que o OAuth 2.0, sozinho, não define.

01Antes do OIDC: o problema que precisamos resolver

Imagine uma organização com cinco sistemas: ERP, Moodle, portal corporativo, sistema financeiro e sistema de atendimento. Sem uma arquitetura centralizada, cada sistema pode possuir seu próprio par de usuário e senha. Isso cria uma lista conhecida de problemas:

• múltiplas senhas e contas duplicadas;
• dificuldade para bloquear usuários desligados em todos os sistemas ao mesmo tempo;
• diferentes políticas de senha entre aplicações;
• dificuldade para implementar MFA de forma consistente;
• maior superfície de ataque;
• esforço duplicado de desenvolvimento a cada novo sistema.

Uma arquitetura mais madura separa essa responsabilidade. Em vez de cada aplicação autenticar diretamente o usuário, a aplicação conversa com um Identity Provider (IdP) — como o Keycloak — usando o protocolo OIDC como intermediário. A aplicação deixa de ser responsável por validar a senha; essa responsabilidade passa para o IdP, e o OIDC define como essa interação acontece.

02OAuth 2.0 e OIDC não são a mesma coisa

Essa é provavelmente a maior fonte de confusão para quem está começando. Imagine um sistema que precisa saber: o usuário está autenticado? Quem é esse usuário? Quais informações posso utilizar? Ele pode acessar determinado recurso?

O OAuth 2.0 resolve principalmente a questão de delegação de acesso. O OIDC utiliza esse mecanismo e acrescenta uma forma padronizada de dizer: "o usuário que passou pelo processo de autenticação é este." Uma forma simples de memorizar:

Na prática, os dois trabalham juntos em qualquer aplicação moderna: o OIDC estabelece quem é o usuário, e o OAuth 2.0 fornece o token que autoriza o acesso às APIs em nome dele.

03Quem participa de uma autenticação OIDC

Existem quatro papéis importantes nesse modelo:

• Usuário — a pessoa que deseja acessar o sistema.
• Client / Relying Party (RP) — a aplicação que deseja autenticar o usuário, como o Moodle ou o Portal Corporativo.
• OpenID Provider — o provedor que efetivamente autentica o usuário. Exemplos: Keycloak, Microsoft Entra ID, Google, Auth0, Okta.
• Resource Server — o servidor que disponibiliza uma API ou recurso protegido (por exemplo, uma API Financeira), e que pode exigir um access token válido para responder à chamada.

04Como uma autenticação OIDC funciona na prática

Considere um cenário simples: o usuário acessa o Moodle, que está configurado para utilizar o Keycloak como provedor de identidade.

Usuário → Moodle → Keycloak → Autenticação → MFA (se necessário)
  → Keycloak gera tokens → Moodle recebe a resposta → Usuário autenticado

A documentação da OpenID Foundation descreve esse processo de forma semelhante: o cliente envia uma solicitação ao OpenID Provider, o provedor autentica o usuário e retorna um ID Token e, normalmente, um Access Token.

05ID Token: identidade e autenticação

O ID Token é uma das principais características que diferenciam o OIDC do OAuth 2.0 puro. Ele contém informações sobre a autenticação e a identidade do usuário, normalmente como um JWT (JSON Web Token) assinado pelo provedor:

{
  "iss": "https://login.exemplo.com",
  "sub": "248931",
  "aud": "portal",
  "name": "Maria Silva",
  "email": "maria@empresa.com"
}

Essas informações são chamadas de claims. O ID Token permite que a aplicação confirme informações relacionadas à identidade autenticada — mas não deve ser confundido com uma credencial de acesso a APIs.

06Access Token: autorização para recursos protegidos

O Access Token tem uma finalidade diferente: representa uma autorização para acessar determinado recurso protegido, como quando o Portal Web chama uma API Financeira apresentando esse token. A API verifica o token e decide se aquela chamada pode ser aceita.

07Claims, scopes e o mecanismo de Discovery

Claims são informações sobre uma entidade — normalmente o usuário — e podem representar identificador, nome, e-mail, grupos, papéis, departamento, organização ou nível de autenticação. A aplicação pode utilizar essas informações para tomar decisões, mas autenticação e autorização continuam sendo responsabilidades diferentes: o fato de o usuário estar autenticado não significa automaticamente que ele possa executar qualquer operação.

O scope representa uma solicitação relacionada aos dados ou permissões que o cliente deseja. O scope fundamental do OIDC é openid, que indica que a solicitação está utilizando OpenID Connect; scopes como profile e email solicitam informações adicionais do usuário, conforme a configuração do provedor.

Outra característica útil do OIDC é o mecanismo de Discovery: em vez de configurar manualmente todos os endpoints do provedor, uma aplicação compatível pode descobrir informações padronizadas — endpoint de autorização, endpoint de token, UserInfo, JWKS e issuer — reduzindo bastante a configuração manual em uma implantação Keycloak.

Por fim, o JWKS (JSON Web Key Set) é o mecanismo pelo qual o Keycloak disponibiliza as chaves públicas usadas para assinar os tokens. A aplicação obtém essas chaves e valida a assinatura — muito mais seguro do que simplesmente confiar em um texto recebido.

08Autenticação x autorização

Essa distinção é fundamental para qualquer arquitetura de identidade:

• Autenticação pergunta: "Quem é você?" — Exemplo: João da Silva.
• Autorização pergunta: "O que você pode fazer?" — Exemplo: João pode consultar contas, mas não pode aprovar pagamentos.

O OIDC é principalmente o mecanismo utilizado para autenticação e transporte padronizado das informações de identidade. A autorização pode utilizar informações trazidas nos tokens, mas a decisão final normalmente pertence à aplicação ou ao mecanismo de autorização adotado pela arquitetura. É perfeitamente possível ter usuário autenticado e, ainda assim, operação não autorizada.

09Onde entra o Keycloak — e o SSO

O Keycloak pode funcionar como OpenID Provider, sendo responsável por autenticar o usuário, executar MFA, manter a sessão de autenticação, emitir tokens, fornecer claims e integrar-se a outras fontes de identidade (como um Active Directory). A aplicação, por sua vez, confia no resultado da autenticação do Keycloak — o que permite centralizar a identidade.

Uma das consequências mais interessantes desse modelo é o Single Sign-On (SSO): se o usuário já autenticou no portal corporativo e depois acessa Moodle, GED e ERP, e todos utilizam o mesmo provedor OIDC, ele não precisa necessariamente informar novamente sua senha em cada aplicação — a sessão de autenticação centralizada permanece no Identity Provider.

10O Authorization Code Flow e o PKCE

Para aplicações Web, o fluxo mais importante costuma ser o Authorization Code Flow: a aplicação redireciona o usuário ao Keycloak, o Keycloak autentica o usuário e devolve um authorization code, que a aplicação então troca por tokens em uma chamada servidor a servidor. A ideia central é que a aplicação nunca recebe diretamente a senha do usuário.

Esse modelo também conta com mecanismos de proteção adicionais para clientes públicos, como o PKCE — Proof Key for Code Exchange, padronizado pelo RFC 7636 para mitigar ataques de interceptação do authorization code. Termos que valem a pena guardar: Authorization Code, PKCE, Redirect URI, Client ID, Client Secret, Scope, ID Token, Access Token e Refresh Token.

No Keycloak, cada aplicação é normalmente cadastrada como um Client, com configurações próprias de Client ID, redirect URIs, scopes, tipo de aplicação e protocolo — o que permite ao Keycloak saber quem está tentando autenticar e para qual aplicação está emitindo aquela autenticação.

11OIDC não elimina a necessidade de segurança na aplicação

Existe uma tentação comum: "estou usando Keycloak e OIDC, portanto minha aplicação está segura." Não necessariamente. O OIDC resolve uma parte importante do problema, mas a aplicação ainda precisa:

• validar corretamente os tokens (assinatura, issuer, audience, expiração);
• verificar scopes e roles antes de liberar uma operação;
• proteger endpoints e sessões;
• implementar a lógica de autorização;
• evitar exposição de tokens em logs, URLs ou armazenamento inseguro.

A segurança passa a ser uma responsabilidade compartilhada: o provedor protege a identidade, e a aplicação continua responsável por utilizar corretamente a identidade e as autorizações recebidas.

12OIDC em comparação com SAML

Outra pergunta comum é se o OIDC substitui o SAML. Não necessariamente — os dois cumprem funções semelhantes de federação e SSO, mas pertencem a gerações e ecossistemas diferentes.

Para novos sistemas Web e APIs, o OIDC normalmente é uma escolha muito natural. Ambientes corporativos, porém, podem continuar utilizando SAML por muitos anos, especialmente devido a sistemas legados e integrações existentes. Um dos pontos fortes do Keycloak é justamente permitir trabalhar com OIDC e SAML ao mesmo tempo, facilitando uma estratégia de transição gradual.

13OIDC é uma peça, não a solução inteira

Um gerente de infraestrutura deve evitar a conclusão apressada de que "temos OIDC, portanto temos IAM." Uma arquitetura completa de identidade envolve também provisionamento (como a conta é criada), desprovisionamento (como o acesso é removido), auditoria (quem acessou o quê) e governança (por quanto tempo esse acesso deve existir). O OIDC resolve principalmente a comunicação padronizada relacionada à autenticação e identidade entre aplicações e o provedor — é uma peça fundamental da arquitetura, mas não é o IAM completo.

14A mudança de pergunta

Em uma arquitetura tradicional, cada aplicação sabe como autenticar seus usuários. Em uma arquitetura baseada em identidade centralizada, a aplicação deixa de ser responsável por autenticar diretamente o usuário e passa a confiar em um provedor de identidade — e o OIDC fornece o protocolo padronizado para estabelecer essa confiança, permitindo implementar de forma centralizada SSO, autenticação, MFA, identidade e integração com múltiplas aplicações, sem que cada sistema precise reinventar seu próprio mecanismo de login.

Para a equipe de infraestrutura, a pergunta deixa de ser "como faço o login deste sistema?" e passa a ser: "como faço este sistema confiar de maneira segura na identidade corporativa?"