How Authlane works

Authlane owns connection policy, hosted OAuth, encrypted credentials, status, and tool definitions. Your SaaS owns user authentication, the AI runtime, and every provider request.

Prerequisites

You need a tenant, a server-side API key, an enabled service, and a stable externalUserId from your authenticated SaaS session.

Implement the workflow

1. Your backend lists the tenant-enabled catalog from Authlane.
2. It creates a short-lived connect session bound to one external user, exact origin, service snapshot, and expiry.
3. The browser opens Authlane's hosted UI. OAuth authorization and callback traffic stays on the Authlane origin, where credentials are encrypted.
4. Your backend binds authlane.user(externalUserId) and reads effective status and definitions.
5. When a local tool callback runs, it requests one fresh audited access-only credential lease.
6. The integration in your SaaS process calls the provider directly.

Browser -> Authlane: hosted connect and OAuth
SaaS -> Authlane: catalog, status, definitions, short-lived lease
SaaS -> Provider: tool request
Provider -> SaaS: provider response

Expected result

Authlane can revoke access, refresh stored OAuth credentials, and report lifecycle state without receiving model tool input or provider response data.

Handle errors

Retry safe control-plane reads with bounded backoff. Send expired or failed connections back through a new connect session. Never retry an ambiguous provider mutation without provider-level idempotency.

Security boundary

Authlane has no tool-execution endpoint, provider proxy, hosted MCP server, or shared user master token. Provider traffic always bypasses Authlane.

Next step

Follow the Quickstart, then review core concepts.