OpenID, une opportunité (manquée) !

Combien de vos expériences en ligne commencent aujourd’hui par ce genre d’écran ?

Ou bien ça ?

Oui, je laisse volontairement de côté la popup pour accepter de vous faire tracer par des cookies, interrompre pendant un bambochage par des notifications push et violer votre smartphone par une application mobile inutile.

Le commun des mortels

Je ne crois pas trop me tromper en avançant qu’en ce qui concerne les mots de passe, nous sommes tous égaux, moins on en a à retenir, mieux on se porte ! Sans compter que la définition d’un mot de passe sécurisé fait encore bien débat : 8 caractères minimum par ci, 6 chiffres maximum par là …

Et pourtant, il est évident qu’une application a besoin d’authentifier une personne afin notamment de ne pas divulguer des données personnelles à un autre utilisateur, jusque là à priori, pas de soucis.

Pendant très longtemps, chaque application gérait ses comptes utilisateurs avec ses mots de passe associés mais cela était forcément frustrant pour les utilisateurs.

Merci les réseaux sociaux !

Bien heureusement, on peut compter sur ces petites pépites de la Silicon Valley pour trouver des solutions à ce soucis et donc aujourd’hui, comme sur les captures ci-dessus, chaque site ou application peut proposer à un utilisateur de se connecter au travers de fournisseurs d’identités comme Facebook, Google, Twitter, #whatever.

Et ça tombe bien, ces entreprises privées, dont le seul intérêt et bien évidemment de nous aider (ou pas), sont bien aises de vous voir créer des comptes pour vous permettre d’atteindre le Graal de l’authentification unique et ainsi de vous voir consommer leurs services puisque “maintenant que vous avez un compte après tout…”.

Vous noterez au passage que chaque site décide quel fournisseur il choisit de supporter et donc quels seront les biais de connexion possibles (en général selon la population ciblée d’ailleurs).

Mais imaginons un peu …

Ne serait-ce pas mieux si je pouvais décider, moi même, d’héberger sur mon propre serveur, un fournisseur d’identité qui me permettrait de me connecter ici et là ?

Et si je n’ai pas les connaissances nécessaires en hébergement, d’utiliser pourquoi pas le fournisseur d’identité de mon association (à laquelle je fais pleinement confiance) pour me connecter à tous les services disponibles ?

Ce faisant, pas besoin de posséder un compte sur un réseau social très douteux en terme d’éthique et de respect de la vie privée. J’ai suscité votre curiosité là non ?

C’est déjà possible !

Si vous êtes développeur, vous savez déjà qu’en soit, l’authentification via ces fournisseurs repose sur le protocole OAuth 2.0 et de plus en plus, sur une évolution de ce dernier OpenID Connect qui nous intéresse aujourd’hui.

Le but de ces protocoles est de permettre l’authentification au travers d’un tiers de confiance, en l’occurence ici, un réseau social. Cela signifie qu’une application est volontairement configurée pour permettre à un utilisateur de se connecter via un réseau social sur lequel il possède déjà un compte et donc de le distinguer d’un autre utilisateur.

Techniquement et traditionnellement, on déclare notre application sur un des fournisseurs, on obtient donc un client id et un client secret, quand un utilisateur demande l’authentification sur l’application finale, il est redirigé par le serveur vers le fournisseur d’identité qui valide ou non ses identifiants et redirige à son tour vers le serveur de l’application finale. Bref, si tout s’est bien passé, on sait donc que l’utilisateur est bien valide et on peut récupérer certaines informations de profil.

Aujourd’hui, techniquement, n’importe quelle librairie d’authentification mise en place pour permettre l’authentification via un fournisseur tel que Google, Facebook ou autre supporte l’authentification via un fournisseur OpenID arbitraire. Par exemple :

• sur Next.js avec NextAuth.js
• sur Nuxt avec nuxt/auth
• en Go avec goth
• en JS avec passport.js
• et ainsi de suite …

Elle est bien bonne celle là ! Mais …

Pour celles et eux encore présent à ce moment là, il y’a une question qui doit vous tarauder encore.

Dans le fonctionnement actuel, on a dit qu’une application devait être enregistrée auprès du fournisseur pour permettre l’authentification à base de client id et client secret, ce qui signifierait que si je développe une application, je devrais l’enregistrer auprès de tous les fournisseurs éventuels, ça en fait du monde !

On devrait mais heureusement, il existe l’OpenID Dynamic Client Registration qui permet à une application de s’enregistrer dynamiquement auprès d’un fournisseur ! Une fois enregistrée, une application peut alors suivre le flux habituel d’authentification.

Pour finir

Je ne suis volontairement pas rentré dans les détails techniques ici, mon propos c’est plutôt de constater qu’en soit, on pourrait remplacer tous les boutons Se connecter avec … par un seul bouton Se connecter avec mon identité, l’url de votre fournisseur (qui pourrait tout aussi bien être Google si le cœur vous en dit) car les spécifications existent, les librairies aussi, seulement les applications choisissent volontairement de restreindre les fournisseurs possibles et nous gardent captifs, parfois sans le vouloir, de ces services douteux.

Du coup, la prochaine fois que vous créez une application, mettez en place l’authentification via OpenID, chiche ?