Voltar ao blog
Fundamentos
OAuth2
OpenID Connect
IAM
JWT

OAuth2 vs OpenID Connect: qual a diferença na prática?

Entenda a diferença entre OAuth2 e OpenID Connect, quando usar cada um e como eles se aplicam em aplicações modernas com autenticação e autorização.

9 min de leitura

OAuth2 e OpenID Connect aparecem juntos em quase toda documentação de login moderno — e muita gente usa os termos como sinônimos. Não são. OAuth2 resolve autorização (o que um app pode fazer em nome de alguém). OpenID Connect resolve autenticação (quem é essa pessoa). Entender essa diferença evita arquiteturas frágeis, tokens mal usados e APIs expostas.

O que é OAuth2, de fato?

OAuth2 define como um client obtém um access token para acessar recursos protegidos sem pedir a senha do usuário a cada integração. O fluxo clássico é Authorization Code: o usuário autentica no Authorization Server, o app recebe um code e troca por tokens no backend.

  • Access token — credencial para chamar APIs
  • Refresh token — renova o access token sem novo login
  • Scope — limita o que o token permite

O que o OpenID Connect adiciona?

OIDC é uma camada sobre OAuth2 que padroniza identidade. Além do access token, você recebe um ID Token (JWT) com claims como sub, email e email_verified. Isso permite que sua aplicação saiba quem logou sem inventar um endpoint proprietário de perfil.

// ID Token (payload simplificado)
{
  "iss": "https://auth.gatekeeperid.cloud/realms/tenant-a",
  "sub": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
  "aud": "my-spring-app",
  "exp": 1710000000,
  "email": "dev@empresa.com"
}

Quando usar cada um?

Só OAuth2 faz sentido quando…

  • Você integra máquina-a-máquina (Client Credentials)
  • O foco é delegar acesso a uma API de terceiros, sem perfil de usuário
  • Você já tem identidade resolvida por outro canal

OIDC é necessário quando…

  • Usuários humanos fazem login na sua aplicação
  • Você precisa de SSO entre produtos
  • Social Login (Google, Microsoft) entra no fluxo
  • RBAC depende de quem é o usuário autenticado

Erros comuns na prática

  • Tratar access token como ID token — expor dados sensíveis no frontend
  • Validar JWT apenas com decode base64, sem verificar assinatura
  • Guardar client_secret em SPA ou app mobile
  • Ignorar aud e iss na validação
  • Implementar fluxo Password Grant em apps públicos

Como o Gatekeeper ID ajuda

O Gatekeeper ID encapsula OAuth2 e OIDC por tenant: realm isolado, emissão de JWT, refresh, login social e API de integração pronta. No Spring Boot, a SDK valida tokens via JWKS e aplica RBAC com @GatekeeperProtected — sem montar um Authorization Server do zero.

Para ir além dos tokens, leia JWT explicado de verdade e Social Login em Java.

Conclusão

OAuth2 autoriza; OIDC autentica. Na maioria dos produtos B2B e SaaS você precisa dos dois. Escolher uma plataforma que já entregue fluxos corretos, multi-tenant e SDK reduz meses de trabalho e superfície de ataque.

Artigos relacionados