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.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s