Sign-in and users

Sign-in and users in Nautilus is the Gate API (/v1/gate/*, for API keys with the gate scope), also called Gate Identity: the identity and access control layer where your end-users register, sign in, and are managed. This section calls it Gate wherever it names the API.

Instead of sprinkling authorization checks across each microservice or rebuilding login flows for the 10th time, Gate centralizes:

  • Identity (who is calling, including your end-users)
  • Tenancy (which tenant / workspace they belong to)
  • Permissions (what they are allowed to do)

What Gate solves

CapabilityDescription
B2B2C User ManagementProvision, authenticate, and store end-user profiles. Every identity is scoped to your tenant.
Login & Registration flowsPassword-based, social (OAuth), and passwordless (email OTP) flows — all exposed as simple REST endpoints.
Social AuthenticationLet end-users sign in with GitHub, Google, and other OAuth providers. Configure which providers to expose per tenant from the Dashboard.
Settings flowEnd-users can change their password and update profile traits via X-Session-Token-authenticated requests — no separate session infrastructure needed.
Email Verification & RecoveryBuilt-in email verification and account recovery flows, routed through your tenant's identity namespace.
MFA / TOTPOptional per-tenant two-factor authentication via authenticator apps (TOTP). Enable or disable from the Dashboard without any code changes.
Passwordless (OTP)Optional per-tenant passwordless login via email one-time codes. Toggle independently from password-based login.
Identity State ManagementActivate or deactivate end-users instantly. An inactive user cannot sign in by any method, their existing sessions stop working, and their Gate access tokens introspect as inactive — no application-level checks needed. Reactivate them and everything works again.
Custom MetadataAttach arbitrary key-value data to any identity via metadata_public. Store plan, company, phone, or any tenant-specific attributes.
Automatic Deletion of Inactive AccountsDelete unconfirmed accounts, and on Pro accounts that have gone unused for months, after a warning email, on a schedule you set per project. See Automatic Deletion.
WebhooksReceive real-time event notifications for every significant identity event (identity.created, identity.login, identity.password_changed, etc.) with HMAC-SHA256 signature verification.
Policy-first access controlFine-grained permissions expressed as policies that are easy to audit and evolve.
Tenant-aware isolationEvery token and end user is bound to one tenant, and a key acts only on its own tenant's users. The same email address can be an end user of two tenants; they are two separate people. See Limits.

The Identity Model

Gate Identity recognizes three distinct types of actors, so that each one's data stays separate:

  1. Verne Admins: System administrators managing the global infrastructure.
  2. Tenants (You): Our customers who build on top of Verne services. You have API keys and access to the Verne Console.
  3. End-Users: Your customers. They interact with your applications. Gate manages their credentials and profiles, ensuring they are strictly scoped to your tenant_id.

Architecture at a glance

Gate Identity exposes a simple HTTP API that your backend, CLIs, and dashboards talk to. Under the hood, it combines a robust, hardened identity server (powered by Ory Kratos) with our custom high-speed policy engine.

For most teams, the integration surface is small:

  1. For API access: Issue a token, attach it to backend requests, and let Gate enforce access centrally.
  2. For User Auth: Forward your end-users' login/registration payloads to Gate, and we handle the secure storage, password hashing, and session management.

Quick Start

  1. Create a tenant in the Verne Console.
  2. Generate a Gate API key in Dashboard → Keys.
  3. Use that API key to:
    • Provision end-user identities via the /v1/gate/identities endpoint.
    • Start a login flow via /v1/gate/auth/login and complete it against the flow's own ui.action URL to get the user's session_token.
    • Obtain short-lived access tokens for your backend via the /v1/gate/tokens endpoint.

Authentication

Every request to the Gate API must include a Bearer token in the Authorization header. A key is vrn_ followed by random characters; it does not name an API. Which APIs it may call is set when you create it, and the Gate API needs a key with the gate scope (shown as Users & sign-in in the dashboard). Keys created before scopes existed and named vrn_gate_... still work and open the Gate API only. See API Keys.

Example header:

Authorization: Bearer vrn_9f8a7...

Keys are scoped to a single tenant, and you create and revoke them on the Dashboard → Keys page.