OAuth 2.0 et OpenID Connect : comment cela fonctionne ?

Ce résumé permet d’acquérir une idée générale. Les développeurs se rapporteront à la rubrique Développer.

Principe

La caractéristique principale d’OAuth 2.0 comme d’OpenID Connect tient au faut fait que l’utilisateur n’a plus besoin de s’inscrire sur chaque application à laquelle il veut accéder car la procédure de connexion (la fourniture du login et du mot de passe) se passe sur le serveur d’authentification. Il est donc nécessaire de ne s’inscire qu’une seule fois. On parle d’inscription unique (Single Sign On, SSO).

Le schéma de processus ci-dessous explicite le concept :

fig 1 : L’application ne voit que des jetons, pas les identifiants personnels.

L’application ne voit jamais les identifiants de connexion (login et mot de passe), ni d’autres informations personnelles qui pourraient être demandées pendant la procédure d’autorisation, celles ci-circulant exclusivement, et de façon cryptée, entre le navigateur de l’utilisateur et le serveur OAuth.

Ensuite, la communication entre le serveur d’authentification et les serveurs d’applications tierces transporte des jetons (Token), et non les identifiants de connexion [1].

Sans entrer dans les détails, notons la magie qui se cache derrière "Call application with access token".
Comment le jeton est-il validé ? Il y a là un sujet généralement laissé dans l’ombre et que nous allons amplement développer, jusqu’à préconiser l’emploi exclusif d’OpenID Connect.

Avantages

La délégation d’authentification (d’une application à un serveur) présente de nombreux avantages :
protection des identifiants de connexion (comme illustré ci-dessus),
enregistrement unique : un seul enregistrement des login et mot de passe sur le serveur d’authentification pour se connecter à toutes les applications compatibles,
connexion unique : une seule fourniture de login et de mot de passe pour une navigation entre plusieurs applications compatibles,
protection de l’accès aux ressources externes tels que les web-services.

Ce dernier point mérite un développement. Alors que le point de vue sur OAuth 2.0 et OpenID Connect est le plus souvent réduit à un moyen de connexion unique (Single Sign On ou SSO), la transmission de jetons aux ressources protégées offre à celles-ci le moyen de vérifier l’authenticité de la requête qui leur est faite, en identifiant l’application qui est à l’origine de la demande [2] ainsi que l’utilisateur final. OAuthSD et OpenID Connect apparaissent alors comme un système de sécurisation global des accès à un ensemble de ressources de type web (API et web service répondant au protocole HTTP) réparties sur les réseaux.