OAuth 2.0 y OpenID Connect

«Iniciar sesión con Google» se ha convertido en algo evidente para el usuario y en una fuente de confusión persistente para el desarrollador. La razón es sencilla: OAuth 2.0 no es un protocolo de autenticación. Es un protocolo de delegación de autorización, concebido para que una aplicación obtenga acceso a un recurso en nombre de un usuario, sin conocer su contraseña. La pregunta «¿quién es este usuario?» no figura en él.

OpenID Connect se creó precisamente para cubrir esa carencia: es una capa de identidad situada sobre OAuth 2.0, que añade un token de identidad verificable y un formato estándar de información sobre el usuario. Emplear OAuth 2.0 solo para autenticar, suponiendo que un token de acceso válido prueba una identidad, es un error documentado que ha producido vulnerabilidades reales: un token de acceso prueba un derecho de acceso, no la identidad de su portador.

Esta lección distingue, por tanto, cuidadosamente ambos conceptos, presenta los cuatro actores y el flujo que se debe usar hoy —el código de autorización con PKCE, siendo los demás obsoletos o reservados a casos particulares—. A continuación configurará los dos roles que Spring Security sabe desempeñar: el de cliente, que delega el inicio de sesión en un proveedor, y el de servidor de recursos, que verifica los tokens que se le presentan.