Access & identity
Authentication
How users securely authenticate into the Telblu platform, and how authentication integrates with enterprise identity providers.
Authentication is the first security boundary within Telblu. The platform supports modern authentication standards, enterprise identity providers and secure session management to ensure authorised users can safely access organisational data.
Available today
Email and password sign-in, Google OAuth, email verification, TOTP multi-factor authentication with recovery codes, and organisation-scoped role-based access.
SAML SSO
Production-ready SAML 2.0 Single Sign-On. Email-first sign-in resolves the organisation's identity provider by domain, redirects the user to their IdP and establishes an organisation-scoped, role-loaded session on return.
Session management
Sessions persist across page loads and refresh automatically. Protected routes re-validate the session on every request; users can sign out at any time.
Not yet implemented
Microsoft OAuth, generic OIDC, SMS MFA, WebAuthn / passkeys, hardware keys, device lists and forced logout are not implemented today.
Authentication flow
Every sign-in follows the same deterministic sequence. Each stage is independently logged, and a failure at any stage halts the flow and returns an explicit denial to the client.
Stage 1
User
Stage 2
Sign-in method
Stage 3
Authentication
Stage 4
Session issued
Stage 5
Role resolution
Stage 6
Row-Level Security
Stage 7
Workspace access
Stage 8
Platform
User
The user opens the Telblu sign-in page from a browser. The client requests an authentication challenge from the platform.
Sign-in method
The user enters their work email. Telblu resolves the authentication method for that domain - organisations with a configured SAML identity provider are automatically redirected to their IdP, everyone else continues with email and password or Google OAuth.
Authentication
Credentials are verified by the managed identity service. Where TOTP multi-factor authentication is enrolled for the account, a second factor is required.
Session issued
On success a session is issued and stored client-side by the managed auth SDK. The session includes an access token and a refresh token.
Role resolution
The user's role assignments and organisation memberships are loaded from the user_roles table for the request.
Row-Level Security
Every subsequent database query is filtered by PostgreSQL Row-Level Security policies scoped to the user's organisation and role.
Workspace access
The user is routed to the workspace their role permits. Attempts to reach unauthorised destinations return an explicit denial.
Platform
Every request is re-evaluated against the user's identity, role and organisation scope.
Supported authentication methods
Telblu supports two primary authentication methods. Both issue the same session type and are evaluated by the same downstream role and permission engine.
Email & Password
Built-inNative identity managed by the Telblu authentication service. Suitable for small teams and any user without an enterprise identity provider.
Secure sign-in
Credentials are submitted over HTTPS/TLS and validated by the managed authentication service.
Managed credential storage
Passwords are stored and hashed by the managed authentication provider. Telblu never handles or logs plaintext passwords.
Email verification
New accounts must verify ownership of their email address before they can sign in.
Self-service password reset
Users can request a password reset from the sign-in page. The managed authentication service dispatches a time-limited, single-use reset link that returns the user to Telblu to set a new password.
Single Sign-On (SSO)
EnterpriseFederated authentication via SAML 2.0 or OpenID Connect. Recommended for all enterprise deployments.
Administration
Administrators configure a SAML 2.0 identity provider metadata URL and email domains per organisation from the Administration → SSO screen.
Domain routing
Email domains are stored on each organisation's SSO configuration so future SSO sign-ins can be routed to the correct identity provider.
End-user SAML sign-in
After the user enters their work email, Telblu automatically initiates the SAML redirect to the organisation's identity provider, processes the callback and establishes an authenticated session bound to the resolved organisation.
Automated provisioning
Automated SCIM user provisioning is not implemented. Roles are assigned by administrators through the Administration screens.
Availability
Available today SAML 2.0 Single Sign-On is production-ready end-to-end. Administrators configure the identity provider metadata URL and email domains per organisation. Users enter their work email, are automatically routed to the identity provider, and return through a SAML callback that establishes an organisation-scoped session with roles loaded and Row-Level Security enforced.
Multi-factor authentication
MFA adds a second verification layer after the primary credential is accepted. It protects against credential theft and is enforced according to tenant policy, user role and workspace sensitivity.
Second factor verification
After the primary credential is accepted, users with MFA enrolled must present a time-based one-time password (TOTP) before the session is issued.
Authenticator apps
TOTP codes generated by standard authenticator apps such as 1Password, Google Authenticator or Authy.
Time-based codes
TOTP codes are short-lived and validated server-side against the shared secret enrolled during MFA setup.
Recovery codes
Single-use recovery codes are generated when MFA is enrolled and can restore access if the authenticator device is lost.
MFA enforcement policies
Administrators can require MFA per organisation through the Administration → MFA screen. SMS, WebAuthn, passkeys and hardware keys are not currently supported.
Authentication lifecycle
The lifecycle describes the full journey of an identity from provisioning through active use to session termination. Each transition is logged and can be audited through the administration console.
Step 1
Account created
Step 2
Email verified
Step 3
First sign-in
Step 4
Authentication
Step 5
Session created
Step 6
Role validation
Step 7
Platform access
Step 8
Sign out / session end
Account created
An administrator invites the user, or the user signs up with an email and password. The account is inactive until the email is verified.
Email verified
The user confirms ownership of the email address before the account can access any tenant data.
First sign-in
The user completes the initial sign-in. Where the organisation policy requires MFA, they enrol a TOTP authenticator and store the recovery codes.
Authentication
Every subsequent sign-in re-verifies the primary credential and, where enrolled, the TOTP second factor.
Session created
The managed auth SDK stores an access token and a refresh token. Refresh happens automatically in the background.
Role validation
The current role assignments and organisation memberships are loaded and applied. Row-Level Security applies these on every request.
Platform access
The user enters the platform and can interact only with the workspaces and data their organisation-scoped role permits.
Sign out / session end
Sessions end through explicit sign-out or expiry of the refresh token. Administrative device management and forced logout are not currently supported.
Identity resolution
After successful authentication, Telblu resolves the authenticated identity into a complete access context. This process translates a trusted identity into the organisational structure and permissions that govern every subsequent platform request.
Step 1
Authenticated user
Step 2
Identity lookup
Step 3
Organisation
Step 4
Department
Step 5
Assigned role
Step 6
Permissions loaded
Authenticated user
The user has presented valid credentials and passed any TOTP challenge that applies to their account.
Identity lookup
The user's authenticated ID is used to load their record from the tenant directory.
Organisation
The user's organisation memberships are loaded from user_roles. All access decisions are scoped to those organisations.
Department
Within an organisation, users are grouped into departments. Membership is assigned by administrators and determines workspace access.
Assigned role
Roles are stored in the user_roles table with organisation scope. Each role controls what the user can see and do.
Permissions loaded
PostgreSQL Row-Level Security uses the loaded roles to filter every query. This is re-evaluated on every request.
Authentication proves who you are. Roles and Permissions determine what you can access.
Authentication confirms that the user is who they claim to be. It does not, by itself, grant any platform access. The resolved organisation, department and role assignments are what translate a verified identity into actionable permissions. See the Roles & Permissions documentation for how those permissions are defined and enforced.
Enterprise identity integration
Available today Telblu supports production-ready SAML 2.0 Single Sign-On. Administrators configure the identity provider metadata URL and email domains per organisation, and end users sign in with their work email - Telblu resolves the correct identity provider, initiates the SAML redirect, processes the callback and establishes an organisation-scoped session with roles loaded and Row-Level Security enforced. Automated SCIM user provisioning, group-to-role mapping and generic OIDC federation are not implemented today; roles remain administrator-assigned per organisation.
Session management
Telblu secures authenticated sessions through short-lived tokens, device binding and continuous validation. Sessions are tracked per-device and can be inspected or revoked at any time.
Managed session tokens
Access and refresh tokens are issued by the managed authentication service. Telblu does not implement its own token signing.
Automatic session refresh
The client SDK refreshes the access token in the background while the user is active.
Protected-route validation
Every authenticated route re-validates the session server-side before the loader or component runs.
Sign-out
The user can end their session at any time. The session is cleared from the browser and revoked at the managed auth service.
Current session
Telblu tracks the current browser session for the signed-in user. Device lists, remote session revocation and forced logout are not implemented today.
This device
Signed in
Session refreshes automatically
Authentication security
Telblu applies defence-in-depth controls at every layer of the authentication stack. These controls protect credentials in storage, in transit and during active use.
Transport security
All authentication traffic is served over HTTPS/TLS. Telblu does not use unencrypted transport for sign-in.
Managed credential storage
Passwords are stored, hashed and validated by the managed authentication provider. Telblu does not store or log raw credentials.
Session protection
Session cookies and tokens are handled by the managed auth SDK. Access tokens are validated on every request.
Audit logging
Sign-in successes, failures, MFA challenges and SSO attempts are written to the application audit log for authorised organisation administrators.
Authentication policies
Policies are configured at the tenant level and can be scoped to roles, workspaces or identity providers. Changes take effect on the next authentication event and are audited in the security log.
| Policy | Description |
|---|---|
| Email verification | New accounts must verify ownership of their email address before they can sign in. |
| TOTP MFA enrolment | Administrators can require TOTP multi-factor authentication for an organisation from the Administration → MFA screen. |
| Recovery codes | Single-use recovery codes are generated when a user enrols in MFA. |
| SAML SSO configuration | Administrators save a SAML 2.0 metadata URL and email domains per organisation. Users on those domains are automatically routed to their identity provider on sign-in. |
| Require SSO | Organisations can enforce SAML SSO - when enabled, password and Google sign-in are blocked for users on the organisation's email domains. |
| Role-based access control | Roles are stored per organisation in user_roles and applied through PostgreSQL Row-Level Security. |
| Sign-out | Users can end their session at any time. Administrative device lists, forced logout and concurrent-session controls are not currently implemented. |
Authentication best practices
The following recommendations help administrators harden the authentication surface, reduce credential risk and maintain a clean identity lifecycle. Each practice can be implemented through the Telblu administration console or identity provider configuration.
Enrol TOTP multi-factor authentication
Best practiceAssign least-privilege roles
WarningVerify emails and remove unused accounts
Best practiceMonitor authentication activity
Info