Authentication
Sign in through an identity provider and manage sessions and workspace membership
Interactive users sign in through an identity provider and receive a session. Sessions support immediate revocation and permission changes. LaserData Cloud stores no user passwords.
Sign-In Flow
To sign in:
- Click Sign In and select Google, GitHub, or Microsoft.
- Authenticate with the provider.
- Return to the Console through the redirect.
The provider authenticates your identity. LaserData then creates the session.
GitHub, Google, and Microsoft are the available interactive sign-in methods. There is no separate LaserData password account. If you cannot use an allowed provider, contact LaserData before creating a deployment.
The profile form also requests your name, Title / Position, and an organization name when creating a workspace. Student or Hobbyist can describe personal use. The organization name can identify your project. Review the profile form's terms checkbox even when the sign-in page also displays a terms notice.
If a welcome email button is unreadable, open laserdata.cloud directly and sign in. Invitations and protected-resource codes still require their specific invitation link or code. The welcome email is not an alternative credential.
Cloud Sign-In and Iggy Credentials
Your provider account signs you into the Cloud Console. Cloud roles control management access. Cloud API keys authenticate management API calls. Iggy usernames, passwords, and Personal Access Tokens authenticate clients that send or read deployment data.
The initial Iggy administrator is named root. This name does not grant access to your computer or identify a Cloud organization role. Use the exact username displayed in the deployment Credentials tab. For applications, create an Iggy user with only the required permissions and issue a token for that user.
Sign-in accounts are managed through account Settings. AWS and GCP accounts for BYOC belong under Organization Cloud Accounts. If Console search does not find an account page, use the corresponding navigation entry.
Sign-Up and Workspace Claim
The first user with a custom-domain email, such as [email protected], claims the domain for their tenant. The platform stores acme.com in the immutable email_domain field, which cannot change afterward. Later sign-ups with *@acme.com go to that tenant. Its join_policy determines the next step.
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 email domains, including gmail.com, outlook.com, and proton.me, do not claim a workspace. Those users receive personal tenants.
Two protection flags apply when email_domain is set. Both are off by default. With block_external_invitations, other tenants cannot invite users from the domain, and requests return 400 invitee_domain_locked. With enforce_domain_only_invitations, invitations can target only the tenant's domain or a claimed division subdomain. External invitations then return 400 invitee_domain_not_allowed.
The sign-up response can include workspace, which identifies the screen that the UI must show next:
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 uses the user-session endpoint POST /account/sign_up. API keys cannot call it because they belong to an existing tenant. Manage the flags under Tenant Settings, then Workspace, or through the Tenant Config API.
Session Security
Sessions use these protections:
| 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)
IP binding limits a session to its original IP address and User-Agent. Users can enable it in their account configuration. It suits stable networks but can interfere with VPN or mobile connections.
Session Management
Revoke Sessions
Revoke all active sessions through the Console or API. The server deletes their session data immediately. Revoked sessions no longer grant access.
Session Limits
The platform limits concurrent sessions per user. If you reach the limit, revoke existing sessions before creating more.
Programmatic Access
Use API keys for CI/CD, CLI tools, Terraform, and other software integrations. They use the same permission model as interactive users. Keys also support IP allowlists and expiry.