Les profils d’authentification – quand Approve doit faire plus que vous connecter

Toute authentification Notakey se termine de la même façon : l’utilisateur lit ce qu’il approuve et appuie sur Approve ou Deny : un oui ou un non signé et auditable. En général, cette réponse débloque une connexion. Mais l’appliance se moque de savoir quelle était la question : un profil d’authentification vous permet d’attacher des callbacks côté serveur à cette réponse, de sorte qu’Approve (ou Deny) peut déclencher tout ce qui dispose d’une API HTTP – un contrôleur de porte, une politique réseau, un système de tickets, un relais intelligent.

QR scan or API call ──▶ auth request ──▶ push/app ──▶ user taps Approve
     (from a profile)                                        │
                                              callbacks fire in the background:
                                              ├─▶ https://door.local/open?…
                                              ├─▶ https://nac/api/policy…
                                              └─▶ anything else you add

Les éléments, tout droit issus du produit :

Un profil définit la demande que voit l’utilisateur (titre, description, période de validité), avec substitution de {variable} ({username}, {user_email}, {state} et consorts) dans n’importe quel champ.
Pour chaque profil, vous attachez des callbacks à des événements : Create (demande créée), Approve, Deny, Response (l’une ou l’autre réponse), Error ou Any. Le nombre de callbacks par profil est illimité, et ils s’exécutent en arrière-plan, si bien qu’une API tierce lente ne bloque jamais l’authentification elle-même.
Chaque URL appelée peut être protégée par des client credentials OAuth 2.0 ou une authentification par en-tête (un jeton partagé) : vous n’êtes pas contraint d’exposer un webhook non authentifié.

Les profils se créent dans le tableau de bord, sous Authentication profiles de votre service ; les demandes peuvent ensuite référencer le profil soit depuis l’API, soit (et c’est ce qui rend les usages du monde physique concrets) depuis un QR code, sans aucune notification push.

Essayez tout de suite : la demo bank vous connecte ainsi

Inutile de nous croire sur parole quant au ressenti : la connexion à la demo bank est ce mécanisme. La page de connexion affiche un QR code ; vous ne saisissez rien sur la page. Ouvrez Notakey Authenticator, appuyez sur le bouton de scan et dirigez la caméra vers l’écran :

Scanner le code crée la demande d’authentification directement sur votre téléphone : c’est le deeplink a=a de la section suivante à l’œuvre. Vous voyez exactement ce que vous approuvez, et un seul appui sur Approve :

…et l’onglet du navigateur depuis lequel vous avez scanné est connecté. La moitié invisible est la plus intéressante : votre approbation déclenche un callback vers le backend de la banque avec le paramètre state de la demande, le backend le fait correspondre à la page en attente, et la session s’ouvre. Champ de nom d’utilisateur, champ de mot de passe, lien « mot de passe oublié » : rien de tout cela n’existe, parce que rien de tout cela n’est nécessaire. C’est le schéma que le reste de ce guide braque sur d’autres cibles.

Exemple concret : la porte qui interroge votre téléphone

Une porte de datacenter avec un QR code plastifié à côté. Le scanner avec Notakey Authenticator crée une demande d’authentification sur-le-champ : l’action de deeplink a=a est documentée comme « demander une authentification sans notification push », si bien que cela fonctionne alors même que personne n’a rien envoyé au téléphone :

notakey://qr?a=a&u=ntk.example.com&k=<service-id>&p=<profile-id>

Encodez cet URI dans un QR code (k est l’ID du service, p l’ID du profil, tous deux visibles dans le tableau de bord) et imprimez-le. Le profil qui le sous-tend :

Titre / description : « Ouvrir la porte du DC — {username}, confirmez par biométrie. » Fixez une validité courte, par exemple 60 secondes : personne ne scanne un code de porte pour y réfléchir pendant cinq minutes.
Callback sur Approve : l’API du contrôleur de porte, https://door-controller.internal/open?door=dc-1&user={username}, protégée par un jeton d’en-tête. Approve → appel HTTP → la serrure s’ouvre.
Callback sur Deny (optionnel mais utile) : une demande qui a bien été créée mais refusée signifie que quelqu’un s’est présenté à votre porte et que le propriétaire du téléphone a dit non : reliez cela à votre système d’alerte. Les variables {response_ip} et {username} racontent l’histoire.
Callback sur Create (optionnel) : une entrée dans le journal d’audit dès que quelqu’un scanne, avant même qu’il ne réponde.

L’expérience utilisateur, c’est le flux de la demo bank braqué sur une serrure plutôt que sur un paiement : scanner, lire ce qu’on approuve, appuyer, et la chose se produit. Aucun badge à cloner, aucun code de porte partagé par toute l’équipe, et chaque ouverture est un événement signé rattaché à une personne.

Exemple concret : une connexion VPN qui configure le réseau

Les callbacks se combinent avec les configurations RADIUS de notre guide 2FA VPN. Un schéma issu d’un déploiement réel, avec un contrôleur Aruba : le VPN authentifie l’utilisateur via RADIUS à travers l’auth-proxy comme d’habitude, puis un callback indique au contrôleur réseau d’activer le bon profil réseau pour cet utilisateur. Connexion et autorisation réseau ne font plus qu’une seule approbation, au lieu de deux systèmes censés être d’accord.

C’est dans le corps du callback que les variables du profil font leurs preuves : {username}, {user_guid} (le GUID Active Directory, utile comme clé stable côté contrôleur) et {state} sont substitués à chaque demande, si bien qu’un seul profil sert tous les utilisateurs.

Côté API

Tout ce qu’un QR code peut lancer, votre backend le peut aussi. L’API de demande d’authentification accepte un paramètre profile (la demande tire alors son titre, son texte et sa validité du profil), ainsi que custom_vars, une table JSON de vos propres paires clé-valeur qui se propagent jusqu’aux champs et aux callbacks du profil. Un système de réservation, par exemple, peut transmettre {"room": "B12", "slot": "14:00"} et afficher exactement cela sur le téléphone, puis le remettre au callback qui déverrouille la bonne salle au bon moment.

Deux détails à connaître avant de vous lancer :

Deny et Error sont aussi des événements. Les callbacks les plus utiles en production ne sont souvent pas ceux du scénario idéal : alertez quelqu’un sur Deny, journalisez Error avec {error} / {error_message} lorsqu’une API de destination a cessé de répondre.
Du point de vue de l’utilisateur, les callbacks fonctionnent en mode « on lance et on oublie ». Ils s’exécutent en arrière-plan ; de nombreux callbacks en parallèle sur une appliance chargée peuvent se mettre en file d’attente. Concevez le côté récepteur pour qu’il soit idempotent : le {uuid} de la demande est votre clé de déduplication.

Où cela s’inscrit

L’authentification était le plus difficile : un oui/non signé, propre à chaque personne, adossé à la biométrie et accompagné d’une trace d’audit. Les profils vous permettent de réutiliser cette primitive pour tout ce qui l’entoure : accès physique, politique réseau, approbations dans les outils internes. Si l’appliance gère déjà vos connexions, le prochain système « qui a approuvé ceci ? » que vous vous apprêtiez à construire n’est peut-être qu’à un profil et un callback de distance.

Guides connexes

Notifications push depuis n’importe quel script : le pendant informatif de la même API
2FA VPN avec RADIUS – l’installation complète de l’auth-proxy : le flux RADIUS sur lequel repose le schéma Aruba
Essayez la demo bank : le même flux scanner-vérifier-approuver, braqué sur une transaction