Authentication
How you sign in to Bytesafe, the sign-in methods available, and how an organization connects its own identity provider for single sign-on.
You sign in to Bytesafe once, with one user, and that user carries across the dashboard and every namespace your organization has. Opening the dashboard sends you to the Bytesafe sign-in screen, and signing in returns you to the page you came from.
Sign-in methods
Every method is passwordless. Your identity comes from a code sent to your mailbox, an account you already hold at a provider, or a key held by your device. The screen asks for your email address first and lists the other methods under Or continue with.
- One-time password (OTP). Type your email address and Bytesafe emails you a 6-digit code. Enter the code to finish signing in. A code stays valid for five minutes, and the screen sends a new one on request.
- Google, Microsoft, or GitHub. Pick the provider, sign in there, and you come back to Bytesafe as the account you used. Only the providers your Bytesafe instance has configured appear on the screen.
- Passkey. Confirm with the fingerprint, face, or PIN that unlocks the device or password manager holding the passkey. Browsers that support it offer a registered passkey straight from the email field.
The first sign-in from an email address that has no Bytesafe user creates that user, so the Sign up link leads through the same screen and the same methods.
Manage your sign-in methods
One user can have several methods at once, and any of them signs you in as the same person. Someone who started with a one-time password can register a passkey and use that from then on, or link a provider account and keep both.
The account Security page holds three lists: the provider accounts linked to your user, the passkeys registered for it, and the sessions currently open. It is also where you end a session on a device you no longer have. Adding or removing a method leaves your user, your team memberships, and everything you own untouched.
Single sign-on (SSO)
An organization that runs its own identity provider (IdP) can connect it to Bytesafe over OIDC. People then sign in with the company account they already use, and access follows the joiner and leaver process the organization already runs: closing the account at the IdP closes the way in to Bytesafe.
Connecting an IdP is arranged with us rather than configured in the dashboard, and availability depends on your subscription. Ask us through the chat in the lower right corner of this page, or email support@bytesafe.dev.
Namespace access and permissions
Signing in establishes who you are, and your organization and your teams decide the rest. Two people who sign in the same way can land on different namespaces, with different things editable in each.
- Your organization owns the namespaces you can open. It is also the list the dashboard draws from when someone is added to a team.
- Your teams inside a namespace carry the permissions. Membership of the everybody team makes you a member of the namespace, and further teams add what you can change. See Manage access and Access and permissions.
When a namespace or a setting you expected is missing, the answer is in your teams and your organization rather than in the method you signed in with.
Tokens for package managers, CI, and the CLI
Package managers, CI jobs, the CLI, and the API use access tokens rather than the sign-in screen. A token carries its own permissions and its own expiry, and CI can exchange a trusted-builder identity for a short-lived one instead of holding a stored secret.
Related
- Concept: Access and permissions
- How-to: Manage access, Manage tokens
- Getting started: Access Tokens