OAuth

« Se connecter avec Google » ou « autoriser cette application à accéder à mon compte Twitter » repose presque toujours sur OAuth : l’utilisateur est redirigé vers le service concerné, s’y authentifie directement (l’application tierce ne voit jamais le mot de passe), puis approuve une liste précise de droits. Le service redirige ensuite vers l’application avec un jeton d’accès limité à ces droits, révocable à tout moment sans changer de mot de passe.

OAuth et WordPress

WordPress ne propose pas OAuth nativement pour son propre système de connexion, mais de nombreuses extensions l’utilisent dans les deux sens : « Connexion sociale » pour authentifier un visiteur via Google ou Facebook, ou des extensions qui se connectent en tant que client OAuth à un service tiers (Google Analytics, une messagerie). Pour transformer WordPress lui-même en fournisseur OAuth (permettre à des applications externes de s’y connecter), il faut une extension dédiée comme OAuth Server ou Application Passwords pour un besoin plus simple.

Exemple

1. L'application redirige vers https://accounts.google.com/o/oauth2/auth?...
2. L'utilisateur s'authentifie chez Google et approuve les droits demandés
3. Google redirige vers l'application avec un code d'autorisation
4. L'application échange ce code contre un jeton d'accès

À ne pas confondre avec

• Une simple clé d’API, qui identifie une application de façon globale : OAuth, lui, accorde des droits limités au nom d’un utilisateur précis, avec son consentement explicite.
• L’authentification classique par identifiant/mot de passe : OAuth ne remplace pas l’authentification de l’utilisateur auprès du fournisseur, il évite seulement de la partager avec l’application tierce.
• OpenID Connect, une couche construite au-dessus d’OAuth spécifiquement pour l’authentification (« qui est cet utilisateur »), là où OAuth pur ne traite que l’autorisation (« que peut-il faire »).