Connexion et utilisateurs

La connexion et les utilisateurs dans Nautilus, c'est l'API Gate (/v1/gate/*, pour les clés d'API qui ont le scope gate), aussi appelée Gate Identity : la couche d'identité et de contrôle d'accès où vos utilisateurs finaux s'inscrivent, se connectent et sont gérés. Dans cette section, on l'appelle Gate chaque fois qu'on désigne l'API.

Au lieu de disséminer des contrôles d'autorisation dans chaque microservice ou de reconstruire des flux de connexion pour la dixième fois, Gate centralise :

L'identité (qui appelle, y compris vos utilisateurs finaux)
L'appartenance à un tenant (à quel tenant ou espace de travail ils appartiennent)
Les permissions (ce qu'ils sont autorisés à faire)

Ce que Gate résout

Capacité	Description
Gestion des utilisateurs B2B2C	Créer, authentifier et stocker les profils de vos utilisateurs finaux. Chaque identité est rattachée à votre tenant.
Flux de connexion et d'inscription	Flux par mot de passe, sociaux (OAuth) et sans mot de passe (code à usage unique par e-mail), tous exposés sous forme de simples endpoints REST.
Connexion sociale	Permettre aux utilisateurs finaux de se connecter avec GitHub, Google et d'autres fournisseurs OAuth. Vous choisissez dans le tableau de bord les fournisseurs proposés pour chaque tenant.
Flux de paramètres	Les utilisateurs finaux peuvent changer leur mot de passe et mettre à jour les traits de leur profil par des requêtes authentifiées avec `X-Session-Token`, sans infrastructure de session distincte.
Vérification de l'e-mail et récupération du compte	Flux de vérification de l'e-mail et de récupération du compte intégrés, routés dans l'espace d'identité de votre tenant.
MFA / TOTP	Double authentification facultative par tenant, avec une application d'authentification (TOTP). On l'active ou on la désactive depuis le tableau de bord, sans modifier le code.
Sans mot de passe (OTP)	Connexion sans mot de passe facultative par tenant, avec des codes à usage unique envoyés par e-mail. Elle s'active indépendamment de la connexion par mot de passe.
Gestion de l'état des identités	Activer ou désactiver un utilisateur final instantanément. Un utilisateur désactivé ne peut se connecter par aucune méthode, ses sessions existantes cessent de fonctionner et l'introspection de ses jetons d'accès Gate les signale comme inactifs, sans aucune vérification à faire dans votre application. Réactivez-le et tout fonctionne de nouveau.
Métadonnées personnalisées	Attacher des données clé-valeur arbitraires à n'importe quelle identité via `metadata_public`. Stockez `plan`, `company`, `phone` ou tout autre attribut propre à votre tenant.
Suppression automatique des comptes inactifs	Supprimer les comptes non confirmés et, avec Pro, les comptes inutilisés depuis des mois, après un e-mail d'avertissement, selon un calendrier que vous fixez par projet. Voir Suppression automatique.
Organisations et rôles	Regrouper vos utilisateurs finaux en organisations, donner à chaque organisation des rôles nommés avec des permissions, et lire qui appartient à quoi, depuis l'API, depuis l'introspection des jetons et depuis le jeton signé. Voir Organisations et rôles.
Journal d'audit	Un enregistrement en lecture seule de qui a fait quoi dans votre compte : clés d'API, paramètres et membres des projets, changements de rôle, ainsi que les connexions et les changements de mot de passe de vos utilisateurs finaux, avec l'adresse IP et le user agent. Conservé 7, 30 ou 90 jours selon l'offre. Voir Journal d'audit.
Jetons signés (JWT)	Un JWT signé pour un utilisateur final connecté, vérifiable hors ligne avec les clés publiques de votre tenant, pour les plateformes qui ne peuvent pas appeler Gate, comme Supabase. En complément du jeton de session opaque, et non révocable. Voir Jetons signés.
Webhooks	Recevoir en temps réel une notification pour chaque événement d'identité important (`identity.created`, `identity.login`, `identity.password_changed`, etc.), avec vérification de signature HMAC-SHA256.
Vérification des permissions	Demander à Gate si un utilisateur peut faire quelque chose dans une organisation : `POST /v1/gate/authorize` répond d'après le rôle que l'utilisateur y détient, en direct. Gate répond ; votre code applique. Voir Autoriser une action.
Isolation par tenant	Chaque jeton et chaque utilisateur final sont liés à un seul tenant, et une clé n'agit que sur les utilisateurs de son propre tenant. Une même adresse e-mail peut être celle d'un utilisateur final de deux tenants ; ce sont deux utilisateurs distincts. Voir Limites.

Le modèle d'identité

Gate Identity reconnaît trois types d'acteurs distincts, pour que les données de chacun restent séparées :

Les administrateurs Verne : les administrateurs système qui gèrent l'infrastructure globale.
Les tenants (vous) : nos clients, qui construisent sur les services Verne. Vous avez des clés d'API et un accès à la Verne Console.
Les utilisateurs finaux : vos clients. Ils utilisent vos applications. Gate gère leurs identifiants et leurs profils, et veille à ce qu'ils soient strictement rattachés à votre tenant_id.

L'architecture en un coup d'œil

Gate Identity expose une API HTTP simple, avec laquelle dialoguent votre backend, vos CLI et vos tableaux de bord. En interne, il associe un serveur d'identité robuste et durci (propulsé par Ory Kratos) et notre propre service pour les jetons, les organisations et les vérifications de permissions.

Pour la plupart des équipes, la surface d'intégration est réduite :

Pour l'accès à l'API : obtenez un jeton, joignez-le aux requêtes de votre backend, et demandez à Gate, depuis votre backend, si le jeton est toujours actif et ce que son utilisateur est autorisé à faire.
Pour l'authentification des utilisateurs : transmettez à Gate les données de connexion et d'inscription de vos utilisateurs finaux ; nous nous occupons du stockage sécurisé, du hachage des mots de passe et de la gestion des sessions.

Démarrage rapide

Créez un tenant dans la Verne Console.
Générez une clé d'API Gate dans Tableau de bord → Clés API.
Avec cette clé d'API, vous pouvez :
- Créer des identités d'utilisateurs finaux avec l'endpoint /v1/gate/identities.
- Démarrer un flux de connexion avec /v1/gate/auth/login et le terminer sur l'URL ui.action du flux lui-même, pour obtenir le session_token de l'utilisateur.
- Obtenir des jetons d'accès de courte durée pour votre backend avec l'endpoint /v1/gate/tokens.
- Remettre à une plateforme qui ne peut pas appeler Gate un JWT signé pour l'utilisateur connecté, voir Jetons signés.

Authentification

Chaque requête vers l'API Gate doit contenir un jeton Bearer dans l'en-tête Authorization. Une clé commence par vrn_, suivi de caractères aléatoires ; elle ne nomme aucune API. Les API qu'elle peut appeler sont fixées à sa création, et l'API Gate demande une clé avec le scope gate (affiché Utilisateurs et connexion dans le tableau de bord). Les clés créées avant l'existence des scopes et nommées vrn_gate_... fonctionnent toujours et n'ouvrent que l'API Gate. Voir Clés d'API.

Exemple d'en-tête :

Authorization: Bearer vrn_9f8a7...

Les clés sont limitées à un seul tenant, et vous les créez et les révoquez sur la page Tableau de bord → Clés API.