Les applications d’entreprises et les particuliers grand public ont besoin de s’appuyer sur des protocoles clairs et universels pour accéder aux ressources d’Internet, autant pour respecter leurs droits de propriété que pour s’authentifier.

La tendance 2018, qui confirme ce que l’on prédisait en 2017, est de se baser sur les protocoles OAuth 2.0 et OpenID Connect 2.0, qui contrairement à ce que son nom laisse supposer n’est pas une véritablement une évolution d’OpenID.

OAuth traite le problème de l’accès par une application à une ressource : image, « credentials », numéro de compte, etc, hébergée par un serveur de ressources, qui agit pour le compte du propriétaire de la dite ressource. OpenID Connect, pour sa part, est une surcouche à OAuth 2.0, sur lequel il superpose le traitement des authentifications. Selon les cas, les chefs de projets se contenteront d’OAuth combiné avec un protocole de leur choix ou d’OpenID Connect, qui englobe OAuth. Dans le paysage d’AHA (Authorization Habilitations Access ou Accounting), ces deux protocoles sont désormais incontournables… et indissociables.

OAuth 2.0 et la délégation d’autorisation

OAuth qui en est à la version 2.0, a été conçu par Blaine Cook et Chris Messina, à l’époque où ils travaillaient chez Twitter, à partir de novembre 2006, sur le constat qu’OpenID n’était pas adapté aux problématiques d’accès à des ressources propriétaires externes. Il a donc déjà 12 ans et il n’est plus une découverte.

Sur le fond, OAuth doit être considéré comme une évolution d’autres protocoles qui se sont succédé dans le temps : AuthSub de Google, BBAuth de Yahoo ! ou encore OpenAuth d’AOL.

Pour bien comprendre son intérêt, il faut le resituer dans son contexte d’usage.

On est dans le cadre d’une application Web Internet à laquelle un usager veut se connecter, mais qui a besoin d’accéder à un autre serveur qui lui contient des ressources dont son usager est propriétaire : sa photo, le logo de sa compagnie, une identité numérique, un profil.

Le cas le plus courant est celui d’un utilisateur qui veut s’identifier avec son UserID/Password Facebook, plutôt qu’avec celui que lui aurait attribué l’application Web à laquelle il est ou veut se connecter. Pour cela il faut donc que l’application Web s’adresse directement à Facebook et récupère ses « credentials ». On dit qu’il fonctionne par délégation, l’usager lui ayant délégué le droit de récupérer les ressources dont il est propriétaire. C’est cet aspect d’AHA que traite OAuth.

Le protocole met en scène quatre « personnages » :

• le « Resource Owner », qui est propriétaire des ressources protégées
• le « Resource Server », qui héberge les ressources protégées, Facebook par exemple ou Google
• le « Client », autrement dit l’application qui demande l’accès aux ressources protégées, celle à laquelle est connecté l’usager sur le Web, qui peut être une application PHP sur un serveur ou du JavaScript chez l’usager, sur son mobile par exemple
• l’ « Authorization Server »  qui délivre les jetons d’accès, après que le propriétaire des ressources l’ait autorisé à le faire

Dans la pratique, le « Resource Server » et l’ « Authorization Server » sont souvent confondus, Facebook pouvant par exemple, jouer les deux rôles. On dira seulement que sur le principe les deux fonctions sont distinctes.

La mécanique OAuth 2.0

Le processus OAuth nécessite d’enregistrer les applications clientes (Web) auprès du serveur d’autorisation. Ce qui revient à préciser que telle application est susceptible de demander le droit d’usage d’une ressource protégée, une application Web auprès du serveur d’autorisation pour accéder aux « credentials » d’un usager, par exemple.

Pour cela, il faudra disposer « ad minimum » de trois informations : l’identité du client, le mot de passe ou une paire de clés pour les clients confidentiels et une ou plusieurs URL de redirection.

In fine, le processus OAuth de demande d’accès à une ressource protégée se traduit par l’envoi d’un jeton (token) à l’application cliente.

Rappelons que le client est ici une application Web et pas l’usager du site.

Le protocole prévoit deux types de jetons : accès et rafraîchissement. Le premier permet d’accéder à la ressource demandée et peut être limité, à la fois dans le temps et en périmètre. Alors que le jeton de rafraîchissement permet seulement d’attribuer un nouveau jeton d’accès, quand celui-ci arrive en « fin de vie ».

Contrairement à OAuth 1.0, la nouvelle version du protocole prévoit plusieurs scénarios, selon le niveau de protection que l’on accorde aux ressources « privées » et le rôle que l’on veut voir jouer par le propriétaire de ces ressources et le serveur d’autorisation. C’est l’un des gros avantages de la version 2.0, qui explique son adoption par la plupart des grands utilisateurs.

Quatre scénarios sont possibles :

• l’autorisation avec un code (Authorization Code Grant), pour un client dit confidentiel, c’est-à-dire capable de conserver les identifiants qui lui sont confiés. Ce qui est le cas typique d’un code client côté serveur, une application qui souhaite accéder à certains services spécifiques d’un usager, les mails de Google, par exemple. Dans ce processus l’application cliente doit intervenir, de même que le propriétaire des ressources et le serveur d’autorisation. L’avantage de ce mode est qu’il permet d’attribuer un jeton d’accès de longue durée à une application Web, ainsi qu’un jeton de rafraîchissement lorsqu’il arrivera à expiration.
• l’autorisation implicite (Implicit Grant), est destinée aux clients publics, qui ne peuvent pas garantir la confidentialité des informations qui leur sont confiées. Elle fait intervenir les mêmes partenaires, les applications étant le plus souvent du JavaScript sur le poste client ou porté par un mobile.
• l’autorisation avec les identifiants du propriétaire des ressources (Resource Owner Password Credentials Grant), qui s’applique lorsque l’application cliente et le serveur d’authentification appartiennent à la même entreprise.
• l’autorisation avec les identifiants du client (Client Credentials Grant), qui ne fait intervenir que l’application cliente et le serveur d’autorisation, appelée souvent « two-legged OAuth » ou 2LO). Elle est utilisée uniquement lorsque l’on veut ajouter des restrictions d’usage et ne fait pas véritablement partie de la panoplie. On la signale simplement pour mémoire.

L’autorisation avec un code

On ne pourra pas entrer ici dans le détail de tous les processus OAuth 2.0 pour lesquels nous reportons nos lecteurs à la documentation disponible sur Internet, à l’IETF en particulier.

Nous allons cependant décortiquer le mode « Autorisation avec un code », le plus complexe et finalement le plus représentatif de la « philosophie » OAuth.

Dans ce scénario, un site Internet souhaite accéder aux informations privées de votre profil Facebook (par exemple).

Vous, le propriétaire de ce profil, êtes redirigé par le site Internet client vers le serveur d’autorisation, ici Facebook.

Si vous acceptez l’accès, le serveur d’autorisation Facebook émet un code vers le site Web demandeur et ce code est échangé entre Facebook et le site contre un token d’accès, de manière totalement transparente pour vous.

Grâce à ce token, le site peut alors accéder à votre profil Facebook.

L’un des avantages de ce système est que vous n’accédez jamais au token, qui est stocké sur le site demandeur. Facebook en profitera pour envoyer d’autres informations comme la durée de validité du jeton et éventuellement un jeton de rafraîchissement. Sans que cela soit systématique.

"access_token": "2c68b644-36f6-11e1-b5bc-67bcc68e2f43"

"refresh_token": "67151562-3694-11e1-8c88-973c3788d6b1"

Bien entendu, comme pour les autres scenarios, les développeurs ne seront concernés que par les API, mais il est toujours bon de savoir comment ça se passe sous le capot… Ca évite le stress...

La complémentarité d’OAuth avec SAML

OAuth et SAML ne sont pas concurrents. Au contraire, ils peuvent être parfaitement complémentaires.

Si vous voulez par exemple autoriser l’un de vos utilisateurs à se connecter à l’un de vos services, vous pourrez très bien imaginer de l’autoriser à utiliser ses identifiants Facebook, Google ou autre, via OAuth, « credentials » qui seront ensuite véhiculés dans votre système par un mécanisme SAML.

On pourra aussi associer SAML et OAuth dans le Cloud.

OpenID Connect

La fondation OpenID est à l’origine d’OpenID Connect, qui en est actuellement à la version 3. Il s’agit d’une couche protocolaire placée au-dessus d’OAuth, avec lequel elle est souvent associée.

L’objet d’OpenID Connect est d’apporter une fonction d’authentification à OAuth, ce dernier n’assurant que la protection des ressources privées.

Il permet de vérifier l’identité d’un usager auprès d’un serveur d’autorisation et d’obtenir des informations sur celui-ci, qui sont émises et stockées dans le format standard JWT (JSON Web Token), qui lui-aussi, prend de plus en plus d’importance.

JWT est normalisé et comporte des données permanentes et des données optionnelles.

En termes de positionnement par rapport à OAuth, OpenID Connect ne s’intéresse donc qu’au candidat à la connexion à un site Web, ce dernier se basant éventuellement sur OAuth pour accéder à une ressource protégée, gérée par un serveur d’autorisation. Les deux protocoles étant regroupés dans OpenID Connect, cela évite de faire appel à deux API distinctes.

Sur le plan « mécanique », OpenID fonctionne de manière classique, un peu dans la manière de SAML, avec un tiers de confiance qui délivre le jeton de connexion, dans un ballet à 3 partenaires : l’usager, l’application Web cliente à laquelle l’usager veut se connecter et le serveur d’autorisation.

Attention cependant à ne pas faire de confusion entre les « clients » d’OAuth et OpenID Connect, qui ne sont pas les mêmes.