Bonjour bonjour ! … C’est le week-end de la grande transhumance croisée entre Juilletistes et Aoûtiens. Moi, je viens d’entamer ma deuxième semaine de congés et je commence à vraiment prendre le temps de maîtriser de nouveaux fondamentaux. L’occasion pour moi de travailler sur OIDC/OpenID Connect. Rien de mieux que de faire d’une pierre deux coups et de travailler sur un IDP un peu particulier : Pocket ID.
Pocket ID, mmmh ?
Pocket ID est un fournisseur d’identité (IdP) open source et déployable via docker-compose ou kube qui permet aux utilisateurs de s’authentifier auprès de services web en utilisant uniquement les fameuses passkeys, l’équivalent grand public des bonnes vieilles clés SSH que l’on utilise depuis des années avec nos connexions serveurs. Mécaniquement, il se distingue par son approche entièrement sans mot de passe, s’appuyant sur la norme WebAuthn pour une connexion simplifiée et sécurisée.
Dans la pratique : une authentification sans mot de passe, donc. Il prend notamment en charge les passkeys via des appareils physiques comme les YubiKeys, mais aussi, plus traditionnellement, les nombreux gestionnaires de mots de passe comme 1Password ou Proton Pass (que j’utilise personnellement, après des années sur 1Password). Un système de contrôle d’accès simple mais puissant : il permet de restreindre l’accès aux applications en fonction de groupes d’utilisateurs spécifiques (auxquels vous pouvez attribuer des mappings entre vos RBAC d’applications et le système de Pocket ID via le protocole OIDC). Il est capable d’utiliser un annuaire LDAP pour se synchroniser avec celui-ci. Enfin, il est compatible avec des tokens JWT pour des clients OIDC que l’on dit « fédérés » avec des IdP différents (bon, je vous avoue que je n’ai pas creusé ce point spécifique).
Ah oui, accessoirement, il est capable de fournir des One-Time Passwords pour des connexions uniques, non compatibles avec les passkeys (pour un bris de glace ou une connexion de type utilisateur/mot de passe avec une application mobile cliente, par exemple). J’en dirai deux mots en fin d’article, dans la partie troubleshooting.
Le procole Open ID Connect
Pour ceux qui connaissent et utilisent le protocole OIDC, ce sera une redite, mais je vais prendre le temps de présenter ce protocole pour ceux qui le découvriraient, comme moi il y a quelques jours. Pour faire simple, OIDC est un système d’échange de tokens qui permet à un « client OIDC » de déléguer son authentification et ses droits d’accès à un serveur, qu’on appelle traditionnellement un IdP (Identity Provider ou Identity Domain Provider – Pocket ID, par exemple). Il existe d’autres protocoles généralement pris en charge par les IdP, c’est le cas notamment d’OAuth (une version simplifiée d’OIDC) et de SAML.
Voici un schéma fonctionnel d’un échange OIDC :
Je vous l’ai écrit avec des mots pour que cela reste simple à comprendre, à dispo si vous voulez un article plus technique sur ce protocole et ce qui se passe exactement.
Installation initiale de Pocket ID
Plus techniquement, le maître-mot ici est la confiance mutuelle, donc je vous conseille fortement de passer en HTTPS et d’utiliser au minimum Let’s Encrypt, pour éviter de galérer pendant des heures sur des problèmes de certificats auto-signés ou des soucis divers liés à des URL non sécurisées ou non autorisées (j’ai tenté dans un premier temps en me disant que je voulais tester rapidement… erreur ! Cela n’apporte que des emmerdes…).
Première chose, installer l’instance Pocket-ID. Ca c’est relativement simple via docker-compose :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
services: pocket-id: image: pocketid/pocket-id:v2 # or ghcr.io/pocket-id/pocket-id:v2 restart: unless-stopped env_file: .env ports: - 1411:1411 volumes: - pocketiddata:/app/data # Optional healthcheck healthcheck: test: [ "CMD", "/app/pocket-id", "healthcheck" ] interval: 1m30s timeout: 5s retries: 2 start_period: 10s volumes: pocketiddata: |
Avec ce manifest, on va rajouter les infos plus critiques/spécifiques dans le .env :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
# These variables must be configured for your deployment: APP_URL=https://auth.vlab.bzh # Encryption key (choose one method): ENCRYPTION_KEY=27ViBI1Bo9FVsbXmjngnaFSXnCumaJ/3yFdmhruodWQ= # --- ne vous inquiétez pas, "the names have been changed to protect the innocents :)" # ENCRYPTION_KEY_FILE=/path/to/encryption_key # --- utilisez plutôt cette méthode, plus secure. # These variables are optional but recommended to review: TRUST_PROXY=true MAXMIND_LICENSE_KEY= PUID=1000 PGID=1000 |
Avec ça, tout est prêt pour Pocket ID ! Bon, le souci, c’est que, par défaut, tout l’emballage reste à faire, avec un reverse proxy (Traefik ou autre). Je vous laisse cette partie, car j’en ai déjà parlé plusieurs fois dans ce blog ces derniers mois ;). Au final, vous devez avoir une URL HTTPS du type https://pocket-id.mondomaine.tld.
La première chose à faire, c’est de configurer l’IdP pour sa première utilisation.
Vous arrivez sur le portail d’accueil. Vous devez créer votre premier utilisateur donc utilisez l’url https://pocket-id.mondomaine.tld/setup.
Rentrez vos informations et appuyez sur Sign up (ou en français si vous avez l’interface localisée). Pocket ID va vous demander d’ajouter votre passkey. Chez moi, c’est Proton Pass qui prend automatiquement le relais 😉
Et voilà, vous êtes désormais automatiquement connecté en tant qu’administrateur. Vous avez enregistré votre première passkey et vous pouvez commencer à interfacer des clients OIDC avec Pocket ID.
Je vais prendre un exemple simple pour illustrer le processus, Arcane en l’occurence, mais une fois que vous avez le coup de main, ce n’est pas compliqué, la logique est toujours la même. Voyons voir ça.
Configuration d’un client OIDC coté Pocket ID
Pour configurer un client OIDC dans Pocket ID, commencez par lui donner un nom et une description pour l’identifier dans l’interface. Indiquez ensuite l’URL de lancement du client (où l’utilisateur sera redirigé après authentification) et une ou plusieurs URL de callback (points de retour autorisés pour votre application). Activez l’option Client public si votre application (SPA ou mobile) n’utilise pas de secret client (en général vous n’avez pas besoin d’activer ça). Pour plus de sécurité, activez PKCE (recommandé pour éviter les attaques CSRF) et Pushed Authorization Requests (PAR) si votre client le supporte. Vous pouvez aussi passer l’écran de consentement pour les clients de confiance (le passage ou l’IDP demande un consentement sur les information qu’il va partager avec l’application), ou exiger une nouvelle authentification à chaque autorisation (si vous êtes parano 🙂 ).
(NDR : les attaques CSRF (ou Cross-Site Request Forgery) exploitent la confiance qu’un site a envers un utilisateur authentifié. Un attaquant incite la victime (déjà connectée à un service, votre banque par exemple) à cliquer sur un lien ou à soumettre un formulaire malveillant, ce qui exécute une action non désirée en son nom (ex. : changer un mot de passe, transférer des fonds, etc.). Le site cible ne peut pas distinguer si la requête vient légitimement de l’utilisateur ou d’un site tiers … enfin dison que c’est compliqué … et hors sujet ^^ )
Enfin, téléchargez un logo pour personnaliser l’affichage, et ajoutez des identifiants client fédérés si nécessaire pour utiliser des JWT émis par des autorités tierces. Allez voir la doc en cas de besoin sur cette fonction spécifique.
Vous noterez qu’une fois sauvegardé, Pocket ID vous fournit toutes les URLs nécessaires pour la configuration de votre client OIDC de son côté (qu’on va voir ensuite). Garder sous le coude toutes ces infos dans une fenêtre à proximité, elles vous seront utiles.
Enfin on va paramétrer le groupe et l’appartenance du user demo dans ce groupe. On l’utilisera pour définir les droits d’accès souhaités dans Arcane ensuite.
Coté Pocket ID, c’est fini. Maintenant, on s’occupe du client OIDC.
Configuration du client OIDC coté Arcane
Maintenant, coté arcane, on va configurer la partie cliente OIDC. Pour cela allez dans Settings->Authentication. Par défaut vous allez avoir « Local authentication » activée » et « OIDC authentication » désactivée. Activez la partie OIDC et ouvrez le chevron des paramètres. Laissez pour l’instant l’authentification locale activé, histoire qu’on ne se coupe pas la branche où l’on est assis en cas de souci 🙂
Pour configurer un client OIDC dans Arcane, renseignez d’abord les identifiants fournis par votre IdP : le Client ID et le Client Secret. Indiquez ensuite l’Issuer URL (ex. : https://auth.vlab.bzh), qui permet à Arcane de découvrir automatiquement les endpoints OIDC. Personnalisez le Provider Display Name (ex. : « vLab IDP ») et ajoutez une Provider Logo URL pour afficher le logo de votre IdP sur la page de connexion le cazéchéan. Définissez les Scopes (ex. : openid email profile, pas besoin de plus en général) pour autoriser l’accès aux informations utilisateur, et précisez le Groups Claim (ex. : groups) qui va nous servir à mapper les groupes utilisateur.
Enfin, on va autoriser un mapping entre le groupe de Pocket ID et celui de Arcane pour que arcane considère que chaque utilisateur membre du groupe claim « admins-pocket-id » qui se connecte via Pocket ID se voir attribué le rôle de viewer.
Enfin configurez la Redirect URI (ex. : https://arcane.vlab.bzh/auth/oidc/callback) dans Pocket ID pour finaliser le flux d’authentification.
C’est terminé, il n’y a plus qu’à tester :
Troubleshooting et conclusion
Bon, une fois toutes ces étapes passées… forcément, ça ne va pas marcher du premier coup chez vous, je pense ! En tout cas, ça n’a pas été le cas chez moi 🙂 .
Surtout, soyez méthodique : n’essayez pas, dans un premier temps, de bidouiller tout de suite. Reprenez et vérifiez chaque étape une par une. On oublie toujours une URL dans la configuration quand on n’est pas habitué, et surtout, utilisez à fond les logs stdout de Docker avec votre instance Arcane actuelle. De plus, ne tentez pas une configuration en production dès le début, ou vous risqueriez d’y passer des heures.
Quelques astuces pour aller plus vite dans votre debugging : utilisez et abusez des contextes de navigateurs différents (Chrome, Firefox, Safari, etc.), et ne négligez pas le mode privé. Pour ce genre de troubleshooting, ça marche bien. Si vous avez des ennuis côté Pocket ID, sachez que vous pouvez aussi piloter l’IdP en ligne de commande avec docker compose exec, par exemple pour forcer l’utilisation d’un login/mot de passe.
Une petite commande qui m’a bien servi :
|
1 |
docker compose exec pocket-id /app/pocket-id one-time-access-token cedric@vblog.io |
Cette commande génère à la volée un token d’authentification direct pour l’utilisateur dont l’email est cedric@vblog.io. Malheureusement, pendant l’écriture de ce billet (le 1er août), l’image de Pocket ID dans sa dernière version 2.12.0 (pocket-id:v2) est buggée pour cette commande en particulier 🙁 🙁 … En espérant que le tout récent commit, qui est censé supprimer cette régression, sorte vite…
Autre conseil perso, comme les passkey sont vraiment compliquées à extraire et à manipuler si vous n’avez pas de password manager (ce qui m’étonnerais chez vous ^^) , faites des exports de la base de production régulièrement pour éviter tout problème de corruption avec ce petit script en cli. (elle marche encore chez moi … ouf !) :
|
1 2 |
DATE=`date +%Y-%m-%d-%H%M%S` docker compose exec pocket-id ./pocket-id export --path - > ./export-${DATE}.zip |
Pour terminer, Pocket ID est vraiment un IDP nextgen qui vous apprendra plein de choses, notamment sur les IDP et plus spécifiquement les passkeys, qui sont vraiment l’avenir du passwordless pour moi. Cerise sur le gâteau, concernant son interface graphique, j’adore sa simplicité et son élégance (typiquement IA comme réponse … qu’est-ce qui t’arrive Cédric, tu bosses trop avec là … ça va mal finir … 🙂 )
Amusez-vous bien !
Références :
– Pocket ID : https://pocket-id.org
– Arcane (pour mémoire) : https://getarcane.app
– Les passkeys : https://www.passkeys.com/index.html
