Sign-in methods

Every surface (AI apps, the CLI, the widget) goes through one branded sign-in page on your project’s host. You choose one or more methods and their order; we never pick for you.

Whatever the method, we verify your user’s JWT (by JWKS, or an HS256 shared secret), store it encrypted in our token vault, map the role, ask for consent, and hand the client a token we mint. Your JWT never reaches the client or the model.

Redirect (callback)

Your login page redirects back to <host>/callback with the user’s token. Best when you have your own login UI, SSO, MFA or a captcha: we never see a password.

Username + password (capture)

A branded form on our page. The fields are relayed once to your login API (for example POST /auth/login) and only the returned JWT is kept.

Passwords are never stored or logged.
Rate-limited per IP and per account.
MFA is not supported here: users who get an MFA challenge are sent to the redirect method.

Token

Token exchange (RFC 8693) at POST <host>/token: your site or server trades its signed-in user’s JWT for ours, with no popup.

Browsers may call it only from your allowed origins.
Servers use a client secret you create in the console (shown once).
Developers can also paste a token (“Advanced” on the sign-in page, or <cli> login --token - from stdin).

SSO

Google, Microsoft (Entra ID), Firebase Authentication, or any OpenID Connect issuer (Okta, Auth0, Keycloak and others).

Register <host>/sso/callback as the redirect URI.
For Firebase, add our host to Authorized domains.
Your API must accept tokens from that identity provider.

Testing and sessions

Each method has a Test button in the console that runs the real flow with a test user.

Sessions refresh silently when you provide a refresh URL, your login returns a refresh token, or your identity provider issues one; otherwise a session ends when your JWT expires and the user signs in again.

End users can see and end their sessions on <host>/account, and you see who is signed in, and how, in the console.