OAuth 2.0 e OpenID Connect

"Entrar com o Google" tornou-se algo óbvio para o usuário e uma fonte de confusão duradoura para o desenvolvedor. O motivo é simples: o OAuth 2.0 não é um protocolo de autenticação. É um protocolo de delegação de autorização, concebido para que uma aplicação obtenha acesso a um recurso em nome de um usuário, sem conhecer sua senha. A pergunta "quem é este usuário?" não faz parte dele.

O OpenID Connect foi criado justamente para preencher essa lacuna: é uma camada de identidade construída sobre o OAuth 2.0, que adiciona um token de identidade verificável e um formato padrão de informações sobre o usuário. Usar o OAuth 2.0 sozinho para autenticar, supondo que um token de acesso válido prove uma identidade, é um erro documentado que já produziu vulnerabilidades reais — um token de acesso prova um direito de acesso, não a identidade de quem o porta.

Esta lição distingue, portanto, os dois com cuidado, apresenta os quatro atores e o fluxo a ser usado hoje — o código de autorização com PKCE, sendo os demais obsoletos ou reservados a casos particulares. Em seguida, você configurará os dois papéis que o Spring Security sabe desempenhar: o de cliente, que delega o login a um provedor, e o de servidor de recursos, que verifica os tokens que lhe são apresentados.