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.
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
audeissna 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.