SSO sans mot de passe avec Notakey : guide de configuration pas à pas

À la fin de ce guide, vos utilisateurs se connectent à une application par une approbation sur leur téléphone : ils saisissent un nom d’utilisateur, ou scannent un QR code, puis confirment dans l’application Notakey. Aucun mot de passe sur la page de connexion. Le mot de passe existe toujours, mais il n’a plus qu’un seul rôle obligatoire : il est demandé une fois, lors de l’enregistrement de l’appareil, pour créer la clé de l’utilisateur. Tout ce qui suit relève de votre politique, et ce guide indique précisément où se règle chacune d’elles.

Chaque service Notakey — ceux que vous utilisez déjà pour le 2FA VPN, Windows ou Wi-Fi — peut aussi agir comme fournisseur OpenID Connect. Pas besoin d’un produit séparé pour cela : activez l’OIDC pour un service dans le Dashboard, enregistrez l’application qui l’utilisera comme client, puis pointez cette application vers les endpoints fournis par Notakey. Aucun certificat SAML, aucun serveur de fournisseur d’identité séparé à faire tourner.

your app ──OIDC──▶ Notakey service (OIDC provider)
                        │
                        ├──▶ user repository: onboarded devices in this service
                        └──▶ push ──▶ user's phone: read, approve

(Les applications d’entreprise qui ne parlent que du SAML classique — Google Workspace, AWS — passent par le fournisseur d’identité SAML séparé de Notakey ; la dernière section indique où le trouver.)

Comment le mot de passe fonctionne réellement ici

Cela mérite d’être précis, car « sans mot de passe » est souvent employé à la légère :

L’enregistrement est le seul mot de passe obligatoire. Défini dans le Dashboard ou repris depuis Active Directory, il est vérifié une seule fois, quand l’utilisateur enregistre son appareil et que sa clé est générée dans le matériel sécurisé du téléphone.
La connexion quotidienne n’en a aucun. L’utilisateur saisit un nom d’utilisateur ou scanne un QR code ; la page de connexion peut même se réduire à un simple scan, sans rien à taper du tout. La vérification d’identité, c’est l’approbation signée dans l’application.
Tout le reste est un réglage, pas une règle. Une application peut exiger une confirmation supplémentaire dans l’app, une autre un mot de passe, une troisième les deux. Vous pouvez aussi redemander le mot de passe à intervalle régulier, histoire que personne ne l’oublie complètement. Tout cela se règle sur un seul écran de configuration, détaillé à l’étape 5.

Étape 1 — Choisir un service

Utilisez un service Notakey existant si ses utilisateurs recoupent déjà ceux de l’application à connecter, ou créez-en un nouveau (Services → Manage → New) si cette application doit avoir sa propre politique de mot de passe, indépendante du reste. La politique définie à l’étape 5 s’applique à tout le service, pas client par client — c’est le critère qui tranche.

Étape 2 — Activer OpenID Connect

Ouvrez le service, puis OpenID Connect configuration → Configure, et cochez Enabled. Laissez le reste aux valeurs par défaut pour l’instant — vous réglerez Require password et Require mfa délibérément à l’étape 5, pas par inadvertance ici. Enregistrez.

Étape 3 — Copier les endpoints

Retournez sur OpenID Connect configuration et cliquez sur Show. Notakey a généré un document de découverte et les endpoints individuels qui se cachent derrière :

https://<your-dashboard-host>/oidc/services/<access-id>/.well-known/openid-configuration

La plupart des logiciels compatibles OIDC n’ont besoin que de cette seule URL : collez-la dans un champ « auto discovery » ou « issuer », et l’application va elle-même chercher les endpoints d’autorisation, de token, d’userinfo et de JWKS. <access-id> est le même identifiant que celui affiché sur la page du service.

Étape 4 — Enregistrer l’application comme client

Dans le service, OpenID Connect configuration → Clients → New client. Notakey génère pour vous un Client ID et un Secret aléatoire.

Deux choses à savoir avant d’enregistrer : le champ Secret est masqué et Notakey ne vous le remontrera plus une fois que vous aurez quitté la page — copiez-le tout de suite, ou bien sélectionnez le champ et collez-y un secret de votre choix, qui fonctionne tout aussi bien et se retient plus facilement. Et le champ Redirect URIs doit correspondre, au caractère près, à l’URL que l’application renvoie pendant la connexion — une barre oblique finale que l’application n’envoie pas suffit à tout casser (voir le piège plus bas).

Renseignez :

Description — de quoi la reconnaître plus tard.
Secret — copiez celui généré, ou remplacez-le par le vôtre.
Redirect URIs — l’URL de callback OAuth de l’application. Séparez par des virgules s’il y en a plusieurs, quand l’application est joignable à plusieurs adresses.
Logout URI — où renvoyer le navigateur après déconnexion. Facultatif.

Une fois quelques applications enregistrées, la liste des clients du service ressemble à ceci :

Étape 5 — Pointer l’application vers Notakey

Les étapes exactes dépendent de l’application, mais le schéma est toujours le même : une URL d’issuer ou de découverte, un client ID, un client secret. Deux exemples concrets tirés d’outils auto-hébergés réels :

Gitea propose une commande CLI pour ça — pas de formulaire web, pas de redémarrage :

gitea admin auth add-oauth \
  --name notakey \
  --provider openidConnect \
  --key <client-id> \
  --secret <client-secret> \
  --auto-discover-url https://<dashboard-host>/oidc/services/<access-id>/.well-known/openid-configuration \
  --scopes openid --scopes profile --scopes email

La page de connexion de Gitea affiche aussitôt un bouton « Sign in with notakey », à côté du formulaire de mot de passe existant — rien n’est supprimé.

Proxmox VE traite cela comme un realm d’authentification, qui s’ajoute à ceux qui existent déjà :

pveum realm add notakey --type openid \
  --issuer-url https://<dashboard-host>/oidc/services/<access-id> \
  --client-id <client-id> \
  --client-key <client-secret> \
  --username-claim sub \
  --scopes "openid email profile" \
  --autocreate 1

Ici, --issuer-url est l’URL de découverte amputée de son suffixe /.well-known/openid-configuration — Proxmox l’ajoute lui-même. --autocreate 1 crée un utilisateur Proxmox correspondant dès la première connexion réussie, sans aucune permission tant que vous ne lui en accordez pas explicitement : il ne distribue pas d’accès par accident.

Étape 6 — Définir la politique de mot de passe

C’est ici que la « liberté de l’administrateur » prend forme concrètement, retour sur OpenID Connect configuration → Configure :

Require password décoché, avec Require mfa coché : le parcours sans mot de passe décrit au début de ce guide. La connexion se limite au nom d’utilisateur (ou au QR) plus l’approbation sur le téléphone, rien de plus.
Require password coché, Password cache laissé à 0 : mot de passe à chaque fois, en plus de l’approbation — la 2FA classique.
Require password coché avec un Password cache exprimé en secondes (par exemple 2592000 pour 30 jours) : sans mot de passe au quotidien, avec une nouvelle demande une fois ce délai écoulé — uniquement pour qu’il ne tombe jamais dans l’oubli. Mfa cache fonctionne de la même façon pour l’étape d’approbation, si vous souhaitez aussi la mettre en cache.

Ce réglage s’appliquant à tout le service, une application qui a besoin d’une politique différente de ses voisines doit avoir son propre service — retour au choix de l’étape 1.

Quand quelque chose ne fonctionne pas

Une erreur redirect_uri mismatch signale presque toujours une barre oblique finale : certaines applications envoient https://app.example.com, d’autres https://app.example.com/, et Notakey compare la chaîne à l’identique. Cherchez dans vos logs nginx ou d’accès de l’application le redirect_uri= littéral envoyé par l’application, et enregistrez exactement cette valeur.
Si l’URL de découverte renvoie une 404, vérifiez que Enabled a bien été enregistré à l’étape 2 — une page de configuration qui a l’air correcte mais n’a jamais été soumise est l’oubli le plus fréquent.
Le journal Authentication activities du service affiche chaque tentative qui a atteint Notakey. Une tentative qui n’y apparaît jamais signifie que l’application n’est jamais arrivée jusqu’à l’endpoint d’autorisation — vérifiez d’abord le client ID et l’URL de découverte.

Ce que ce guide laisse volontairement de côté

Les intégrations SAML 2.0 classiques pour les applications qui ne parlent que du SAML — Google Workspace, AWS, et autres — passent par le fournisseur d’identité SAML séparé de Notakey, pas par le chemin OIDC décrit ici. LDAP/Active Directory comme répertoire d’utilisateurs, les configurations multi-tenant et la personnalisation de marque restent également hors de ce guide. Tout cela figure dans la référence CLI et API, avec les tableaux de paramètres complets ; ce guide, lui, est le chemin le plus rapide pour passer de zéro à une connexion sans mot de passe fonctionnelle.

Voyez-le avant de le construire

Le moyen le plus rapide de juger l’expérience de connexion est d’essayer vous-même le parcours d’approbation : essayez la démo en ligne et signez une demande depuis votre téléphone en deux minutes environ, ou demandez une démo et nous ferons correspondre vos applications et votre politique de mot de passe à un pilote sur votre propre infrastructure.