Accueil > OpenID Connect OAuth Server par DnC > OAuth 2.0 : comment cela fonctionne ?

OAuth 2.0 : 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.

La caractéristique principale d’OAuth 2.0 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) . OpenID Connect hérite de ce principe.

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 OAuth et les serveurs d’applications tierces transportent 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.

La délégation d’authentification 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 de façon certaine l’application qui est à l’origine de la demande 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 répartie sur les réseaux.

Notes

[1Soulignons cette communication de serveur à serveur, ou "background connection" : dans le cas d’OpenID Connect, seul le flux "Authorization code" ne passe jamais les jetons par le navigateur du client final, raison pour laquelle nous mettrons au deuxième plan les autres flux dans le cadre d’OAuthSD (bien que ces flux soient implémentés par OAuthSD).