Authentication & Access
Lens supports passwordless and 2FA-backed sign-in out of the box, with SAML / OIDC SSO available on Enterprise. This page covers what's available, which plans include it, and the operational shape of each method — for workspace admins setting Lens up for their team and for IT or security reviewers evaluating the product.
Sign-in methods
Magic link All plans
Passwordless email sign-in. The user enters their email address, receives a time-limited link, and is signed in when they click it. No password is set or stored. Magic link works out of the box with no admin configuration. Links expire after 15 minutes; a given link is single-use.
Google OAuth 2.0 All plans
Sign in with a Google account. Lens does not enforce 2FA itself on the Google path — but if the user's Google account has 2FA enabled, it applies automatically. For organizations standardized on Google Workspace, this is the simplest sign-in method to roll out and audit.
TOTP — authenticator app All plans
Users self-enroll a TOTP-compatible app (Google Authenticator,
1Password, Authy, etc.) from
/settings/profile. Once enrolled, magic-link sign-ins
prompt for a 6-digit code before issuing a session. Users on the
Google OAuth path don't see a TOTP prompt — Google enforces 2FA
on the account itself.
Single-use recovery codes are generated at enrollment and shown
once. Users who lose access to their authenticator can sign in
with a recovery code; admins can reset TOTP for a locked-out
teammate from /settings/users. TOTP secrets and
recovery codes are encrypted at rest.
SAML / OIDC SSO Enterprise
Integrate with your existing identity provider — Okta, Azure AD, Google Workspace, OneLogin, JumpCloud, or any SAML 2.0 / OIDC provider. User provisioning and deprovisioning follow your IdP: when an employee leaves and your IdP deactivates them, their Lens access ends with the next session expiry.
SSO configuration is sales-led — your IT team and ours exchange metadata documents during onboarding. Contact sales to start.
API keys
Workspace-scoped credentials for MCP server access and programmatic
clients (CI scripts, internal automation). Created and revoked from
/settings/api-keys. The plaintext key is shown once at
creation; Releap stores only a SHA-256 hash, so we cannot recover a
key after creation — only revoke it. Every creation, name change,
and revocation is recorded in the audit log.
API keys carry the same workspace scope as the user who created
them. Revoke a teammate's keys before they leave by visiting their
row on /settings/users.
MCP OAuth — agent access
For MCP clients (Claude Code, Cursor, custom agents) Releap implements
OAuth 2.1 with PKCE. Users grant short-lived tokens to a registered
MCP client without pasting long-lived secrets. Tokens are scoped to
the workspace, listed alongside API keys on
/settings/connected-agents, and revocable from the same
page. Scopes are read-only — an MCP client can query the codebase
and read citations, never write.
Sessions
Sessions are server-side and identified by an opaque UUID. Cookies
are HttpOnly, Secure, and
SameSite=Lax. Browser-side scripts cannot read the
session ID; the cookie is only sent to releap.app subdomains.
Default session lifetime is 30 days, refreshed on activity. Users can
view active sessions and revoke any of them from
/settings/profile. A workspace admin can force-sign-out
a teammate by removing them and re-inviting; SSO-managed users sign
out automatically when their IdP session ends.
Preparing a security review?
The full controls model — read-only GitHub access, default-deny on repository visibility, encryption at rest, audit logging, and the BYO LLM data-residency posture for Enterprise — lives on the security page. For pre-procurement documentation (SOC 2 status, DPA, security review questionnaires), contact our team — we respond within one business day.