Authentication
SSO-based authentication with session management and instant revocation
LaserData Cloud uses session-based authentication for interactive users. Sessions provide instant revocation, immediate permission updates, and defense-in-depth security.
Sign-In Flow
- Click Sign In and choose your identity provider - Google, GitHub, or Microsoft
- Authenticate with the provider
- A secure session is created and you're redirected to the Console
No passwords are stored by LaserData Cloud. All identity verification is delegated to the SSO provider.
Sign-Up and Workspace Claim
The first user signing up with a custom-domain email (e.g. [email protected]) automatically claims that domain for their tenant. The platform stores acme.com on the tenant as email_domain (immutable). Anyone signing up later with another *@acme.com address is routed to the existing tenant; what happens next is decided by the tenant's join_policy:
join_policy | Effect on a same-domain signup |
|---|---|
invite_only (default) | The user is created but not added as a member. They land on an "ask your admin for an invite" screen. |
request_to_join | The user is created and a pending join request is published; the tenant owner is notified. The user lands on a "request sent" screen. |
open | The user is auto-joined as a member with the system viewer role; the tenant owner is notified. The user lands on the dashboard. |
Public-domain emails (gmail.com, outlook.com, proton.me, etc.) skip the claim entirely and create a personal tenant, the same as before.
The tenant gets two domain-defense flags, both off by default and only meaningful while email_domain is set:
block_external_invitations- other tenants cannot invite users on this domain. Trying to do so returns400 invitee_domain_locked.enforce_domain_only_invitations- this tenant can only invite users on its own domain (or a claimed division subdomain). External invites return400 invitee_domain_not_allowed.
The sign-up response carries an optional workspace discriminator so the UI can render the right post-signup screen:
workspace value | When it fires | What follows |
|---|---|---|
joined | Same-domain signup, policy open | The user is a tenant member; redirect to the dashboard. |
join_requested | Same-domain signup, policy request_to_join | The user is signed up but not a member; show "request sent". |
awaiting_invitation | Same-domain signup, policy invite_only | The user is signed up but not a member; show "ask for an invite". |
| (field absent) | Standard signup (public-email or no domain match) | Existing flow: create personal tenant or follow invitation link. |
Sign-up runs through a user-session endpoint (POST /account/sign_up); API keys cannot reach it because they are tenant-scoped and only exist for an already-provisioned tenant. Manage these flags in the Console under Tenant Settings → Workspace or via the Tenant Config API.
Session Security
Sessions are protected with multiple layers:
| Protection | What It Does |
|---|---|
| HttpOnly cookie | Prevents JavaScript from reading the session token |
| Secure flag | Cookie is only sent over HTTPS |
| SameSite policy | Prevents cross-site cookie sending |
| CSRF protection | Server-side token validation on all mutating requests |
| Encrypted storage | Session data is encrypted at rest |
| Token hashing | Raw session tokens are never persisted - only hashes are stored |
| Absolute lifetime | Sessions expire after a maximum time regardless of activity |
| Sliding expiry | Sessions also expire after a period of inactivity |
IP Binding (Optional)
Users can enable IP binding on their account, which locks sessions to the originating IP address and User-Agent. This is useful for administrators on stable networks but is opt-in since it may not work with VPNs or mobile networks.
Session Management
Revoke Sessions
You can revoke all active sessions at once from the Console or API. Revocation is instant - all session data is deleted server-side.
Session Limits
The platform enforces a maximum number of concurrent sessions per user. Exceeding the limit requires revoking existing sessions.
Programmatic Access
For CI/CD pipelines, CLIs, Terraform, and other programmatic access, use API Keys instead of interactive sessions. API keys use the same permission model and support IP allowlisting and expiry.