Authentication
Dieser Inhalt ist noch nicht in deiner Sprache verfügbar.
Authentication
Section titled “Authentication”Overview
Section titled “Overview”Rokks authenticates browser users before they can access tenant or environment data. Integrators configure the supported identity provider and decide which users can access which scopes.
How it works
Section titled “How it works”The browser signs in through the configured authentication flow. The Android app uses mobile-capable flows exposed by the same platform, such as passkeys, mobile magic links, native Google sign-in, or recovery-code access when enabled. Clients attach the current session to supported platform requests. Backend services use platform-managed service identity for internal communication. Public integrators should not script against private service addresses.
Before rendering a sign-in method, Rokks verifies the public hostname context and its provider configuration. A provider, storage, network, or payload error shows a retryable Sign-in unavailable state; it is never interpreted as an empty configuration or a platform hostname.
Enterprise branded-domain configuration and public branding are present, but cross-host OIDC/SAML session handoff is a pre-launch blocker and is not production-supported yet. The target uses host-only sessions and a short-lived, single-use exchange to the exact validated target origin. Once certified, tenant-only Exclusive and Auto SSO modes expose only the tenant’s configured OIDC/SAML providers; platform providers and console recovery are not an escape path.
Interactive enterprise providers are selected by the exact provider and environment tuple returned by Rokks; clients must not infer a provider from its kind or choose the first result. Rokks rechecks the current hostname policy, SSO entitlement, environment, and enabled provider at callback time.
Google, Microsoft, and federated OIDC browser flows use single-use state, nonce,
and PKCE, then verify the returned ID token against the issuer’s JWKS before a
platform session is created. Federated OIDC requires an explicit verified email;
Microsoft preferred_username is only an unverified account label and cannot
authorize cross-provider linking. Provider-specific
authorization parameters cannot replace Rokks-owned state, nonce, PKCE, scope,
response type, or redirect URI.
An enterprise OIDC provider is a confidential client with an explicit HTTPS
issuer, client ID and secret, unique scopes containing openid and email, an
explicit group-claim name or null, and a closed set of optional authorization
parameters. The same closed schema is enforced when an administrator saves it
and when Auth starts it. OIDC subjects, already-lowercase email addresses, and
group arrays are bounded and rejected rather than trimmed or repaired.
SAML uses a signed, short-lived RelayState transaction and requires the posted
state plus InResponseTo to match the request that Rokks issued. Operators must
provide an HTTPS entry point, IdP certificate, matching persistent SP private
key and certificate, explicit NameID format, and a complete exact attribute
map. Rokks never generates an ephemeral production identity. Attribute
mappings are exact, not first-match fallbacks. SAML single logout is not
currently supported or advertised.
OIDC state, SAML RelayState, and SAML request-ID correlation use bounded, single-use, fail-closed admission. Distributed flood and cross-host transaction certification remain pre-launch work; the platform does not weaken replay checks to preserve availability.
Every platform session has one principal identifier: JWT id and sub both
equal the canonical Rokks IAM user ID. An identity provider’s subject is kept
separately as provider linkage and never becomes the downstream JWT subject.
Tenant grants are exact signed data; malformed or prototype-reserved map keys
are rejected rather than repaired. Rokks bounds the complete signed session to
one browser-cookie budget and fails explicitly when a grant snapshot cannot fit.
OIDC and SAML group mappings are authoritative on every login. If no current
rule matches, the user is reduced to the base member role with no environment
grant; deleting the last matching rule therefore removes the old privilege on
the next login. Built-in providers preserve manually administered access, while
SCIM follows its explicit push contract.
Federated identity verification completes before Rokks checks new-account admission, and admission completes before any IAM row is created. Ordinary login resolves only the exact provider subject and never links an occupied email. An inactive account is denied. If the deployment has no available system-level registration authority, an unknown identity fails closed instead of being silently provisioned. Invite activation and explicit multi-provider binding require their own purpose-bound transaction and are not implicit login behavior.
Session claims are validated before signing and again at the session probe.
Roles, environment and tenant grants, groups, capabilities, and the revocation
generation must be explicit. An empty environment grant remains empty, and
wildcard access is restricted to owner/break-glass sessions. Session and
identity-transaction cookies are Secure in local HTTPS as well as deployed
environments.
Native Google and mobile magic-link endpoints require the
mobile_viewer client type. The mobile magic-link server URL is deployment
configuration, not client input.
Step-by-step
Section titled “Step-by-step”- Configure the identity provider for your organization.
- Map users or groups to roles.
- Assign environment access.
- Assign tenant access.
- Confirm the user can sign in.
- Verify the user sees only expected dashboards, sources, and jobs.
Common mistakes
Section titled “Common mistakes”Do not confuse authentication with data access. A user can sign in and still lack access to a specific environment or tenant.
Do not share service credentials with browser clients or automation scripts. Use supported public API entry points and scoped sessions.