OAuth 2.0 et OpenID Connect

« Se connecter avec Google » est devenu une évidence côté utilisateur, et une source de confusion durable côté développeur. La raison est simple : OAuth 2.0 n'est pas un protocole d'authentification. C'est un protocole de délégation d'autorisation, conçu pour qu'une application obtienne l'accès à une ressource au nom d'un utilisateur, sans connaître son mot de passe. La question « qui est cet utilisateur ? » n'y figure pas.

OpenID Connect a été créé précisément pour combler ce manque : c'est une couche d'identité posée sur OAuth 2.0, qui ajoute un jeton d'identité vérifiable et un format standard de renseignements sur l'utilisateur. Employer OAuth 2.0 seul pour authentifier, en supposant qu'un jeton d'accès valide prouve une identité, est une erreur documentée qui a produit de vraies vulnérabilités — un jeton d'accès prouve un droit d'accès, pas l'identité de son porteur.

Cette leçon distingue donc soigneusement les deux, présente les quatre acteurs et le flux à utiliser aujourd'hui — le code d'autorisation avec PKCE, les autres étant obsolètes ou réservés à des cas particuliers. Vous configurerez ensuite les deux rôles que Spring Security sait tenir : celui de client, qui délègue la connexion à un fournisseur, et celui de serveur de ressources, qui vérifie les jetons qu'on lui présente.