Sign-in and users

Sign-in and users in Nautilus is the Gate API (/v1/gate/*, for API keys with the gate scope): 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.

Nautilus is EU-hosted: your end users' identities are stored on servers in France, at OVHcloud. Verne Software, the company behind it, is registered in Serbia.

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.
Organizations and rolesGroup your end users into organizations, give each organization named roles with permissions, and read who belongs where — from the API, from token introspection, and from the signed token. See Organizations and Roles.
Audit LogA read-only record of who did what in your account: API keys, project settings and members, role changes, and your end users' sign-ins and password changes, with the address and user agent. Kept 7, 30 or 90 days by plan. See Audit Log.
Signed tokens (JWT)A signed JWT for a signed-in end user, verifiable offline against your tenant's public keys — for platforms that can't call Gate, like Supabase. Additional to the opaque session token, and not revocable. See Signed tokens.
WebhooksReceive real-time event notifications for every significant identity event (identity.created, identity.login, identity.password_changed, etc.) with HMAC-SHA256 signature verification.
Permission checksAsk Gate whether a user may do something in an organization — POST /v1/gate/authorize answers from the role the user holds there, live. Gate answers; your code enforces. See Authorize Action.
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 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 Nautilus. You have API keys and access to the dashboard.
  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 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 own service for tokens, organizations and permission checks.

For most teams, the integration surface is small:

  1. For API access: Issue a token, attach it to backend requests, and have your backend ask Gate whether it is still active and what its user may do.
  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 an account.
  2. Create an API key with Sign-in and users ticked on Dashboard → API 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.
    • Hand a platform that can't call Gate a signed JWT for the signed-in user — see Signed tokens.

The dashboard that sits over all of this, and the sign-in screens it leaves to you, are described on Ory Kratos UI.

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 Sign-in and users 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 → API Keys page.