Authentifier des utilisateurs Couchbase avec OpenID

Attention, pour les non techniciens, ça va piquer.

Donc, j’ai démarré récement une mission, dans laquelle je dois synchroniser une application mobile avec un serveur. le client comme le serveur utilise Couchbase, donc on va utiliser Sync Gateway. Sur le papier, ça paraît tout à fait raisonnable.

Là où ça l’est moins, c’est qu’on ne veut pas stocker de bases d’authentification (la CNIL, tout ça, c’est trop pénible). On va donc passer par de l’OpenID Connect (ce qui est conceputellement très cool). Et comme l’application est mobile-only, on va utiliser ce qu’ils appellent le flow implicite.

Il est assez bien décrit dans la doc de Couchbase Sync Gateway, et en particulier dans ce diagramme

images-003

Présenté comme ça, c’est simple. Mais en fait, c’est rempli de subtilités.

Un token, Quel token ?

D’abord, il faut obtenir le token JWT auprès de votre fournisseur.

Dans mon cas, c’était Auth0, donc un appel à /authorize avec les bons paramètres va renvoyer (via l’url de redirection) le token JWT. Pour ceux qui développent une application JavaFX, il y a une chouette question StackOverflow qui donne un bon exemple … mais je n’arrive plus à remettre la main dessus.

Poster le token ?

Bon alors vous voyez cette jolie image là-haut ? Elle donne toute la doc de Couchbase sur ce qu’il faut faire du token. J’ai essayé pendant une semaine différentes méthodes avant d’utiliser la seule vraie solution : regarder le source !

Ben oui, parce que la sync gateway de Couchbase est écrite en Go.

Donc, j’ai compris assez vite que ça se passait dans le dossier /rest, et en particulier dans le fichier session.go, qui sert de handler pour les urls de … session.

SAUF QUE en go, comme en d’autres langages, on utilise des intercepteurs pour la sécurité. Donc la gestion des authentifications se partage entre handler.go et auth.go. Pour être plus clair, dans handler.go, la gestion de l’authentification se fait dans cette fonction

En fait, si vous regardez le code, vous verrez que h.getBearerToken() lit en fait le token OpenId depuis les entêtes de la requête. Ca fait déja une réponse facile à trouver :

Il faut mettre le bearer token dans les entêtes HTTP, et PAS dans le corps du POST.

Oui, mais quel token ?

Donc, j’en étais là, et à chaque fois que je postais mon token, avec tous les logs activés en mode debug, j’avais à peu près cette suite de messages

Bon, je vous fais grâce des détails, mais dites-vous que ça signifie que mon token est bien passé à la couche go-oidc, qui le refuse. Et là, j’ai dû lire le code environ 2 jours dans tous les sens avant de comprendre.

Alors, autant vous le dire, il y a plusieurs types de token JWT.

maxresdefault

Et en fait, la différence se fait dans l’algorithme. Vous avez le choix entre HS256 et RS256. Et la seule différence, c’est que le RS256 est signé avec un algorithme assymétrique.

Par défaut, Auth0 propose du HS256.

Et évidement, go-oidc ne décode que les tokens RS256. Et le choix de l’algorithme se fait dans les paramètres avancés du client Auth0.

Autrement dit

Utilisez l’algorithme RS256.

Une fois que vous aurez fait tout ça, vous pourrez bénéficier de l’authentification OpenId Connect pour vos synchronisations. Et ça vous créera les utilisateurs automatiquement. Bon, le nom des utilisateurs dans votre sync gateway sera leur id Auth0, mais franchement, vous allez vous laisser arrêter par ce genre de détail ? Moi non plus. D’ailleurs, je m’en vais de ce pas proposer une pull request à Couchbase pour modifier les différents éléments manquants.

Mon fournisseur OpenID est mort !

Et meeerde.

Un fournisseur OpenID, c’est un mec qui s’engage pour dire que je suis bien moi-même. C’est un peu le valet qui porte ma carte d’identité sur internet. Ca m’est surtout très utile chez StackExchange, qui utilise massivement OpenID (pour des raisons bien documentées).

j’avais choisi il y a un moment ClaimID, essentiellement parce que ça n’était pas Google. Hélas, si ça n’est pas Google, ça veut aussi dire que ça peut être une entreprise plus fragile. La preuve ?

ClaimID.com - Opera_2013-12-20_10-02-14

Eh ouais : ClaimID a fermé. Comment je fais pour me connecter chez StackExchange maintenant ? Hein ? Il va falloir que je me trouve un autre fournisseur (qui pourrait être WordPress.com ou StackExchange). Qui pourrait être aussi mon serveur perso, même si je pense pas que ce sot la meilleure des idées …

Pour l’instant, j’ai rajouté WordPress à mes fournisseurs OpenID chez StackExchange, en attendant autre chose …

Bon, pour l’instant, je vais essayer de basculer mon authentification StackExchange vers … autre chose (WordPress, sans doute), mais je ne sais pas si ce sera bien facile …

Est-ce qu’il serait temps de quitter claimid ?

Ce mois-ci, hasard ou coïncidence, gawker a été attaqué par Anonymous.
Bon, les raisons de l’attaque ne m’intéressent pas trop (après tout, j’ai déja dit qu’Anonymous, c’étaient juste une bande de hackers mercenaires qui se tournent les pouces).
Ce qui m’intéresse plus, et ce que dit Jeff Artwood dans cet article, c’est que la sécurité de Gawker, basée sur des mots de passe stockés sur au plus 8 caractères (ce qui casse pas mal l’intérêt de Keepass), est juste misérable.
Et évidement, pour éviter ça, les gens bien informés ont remplacé la sécurité par site, avec des mots de passe différents – ou pas – à chaque fois, par une sécurité utilisant un protocole un peu plus intelligent, délégant la sécurité du site à un fournisseur de sécurité. Ca s’appelle OpenID (voir aussi le site officiel).
Sur le papier, c’est très bien, même si il semble que l’implémentation en soit un peu délicate.
L’un des risques (qui donne le titre à ce message) est le choix d’un mauvais fournisseur.
J’ai choisi il y a longtemps ClaimID, alors que Google n’avait pas encore ouvert son service.
Seulement j’ai appris une chose d’internet au cours des dernières années : si je ne suis pas le client, je suis le produit.
Et si il y a bien un domaine dans lequel je ne veux pas être pris en otage dans les mailles d’une entreprise, c’est celui de mon authentification. or c’est ce que je fais avec OpenID : je laisse une entreprise s’en occuper pour moi.
Il est donc peut-être temps pour moi de changer de crémerie.
Peut-être pour une association ?
Peut-être pour un script hébergé chez free … ou sur mon NAS (ce qui serait un peu audacieux, vu mes expériences en tant qu’administrateur).
En tout cas, sûrement pas chez google, enfin je crois …