Skip to content

How operators sign in

Operators, the people who administer Tavrik, not the clinicians using it, sign in to the console through your own identity provider. This page is for the IT team connecting it.

How operators sign in Operators sign in through the hospital's own identity provider using OIDC or SAML. The console owns the sign-in state and checks it; the admin API only ever sees the identity provider's assertion and issues a short-lived session. Accounts are not created automatically unless the hospital turns that on. The root role cannot sign in through SSO and is reserved for break-glass use with an API key. How operators sign in Tavrik Pty Ltd, trading as Tavrik AI © 2026 Tavrik Pty Ltd, trading as Tavrik AI. All rights reserved. Operator Opens the console Redirected to your sign-in page Tavrik console Owns and checks the sign-in state Never handles your password OIDC or SAML assertion Your sign-in (IdP) Entra ID, Okta, Keycloak, ADFS Your MFA, your account rules assertion only, no state Tavrik admin API Verifies the assertion, issues a short-lived session; logs the sign-in Session Expires; renewed while in use Every action tied to the operator Accounts are not created automatically unless you turn it on. The root role cannot sign in through SSO.

The shape

Section titled “The shape”

The console sends the operator to your identity provider, which authenticates them and returns an assertion. The admin API sees that assertion and, if it maps to a known operator, issues a short-lived session. The console holds the session; the admin API is the thing that decides whether it is valid on every request.

OIDC and SAML are both supported.

What your identity provider is trusted for

Section titled “What your identity provider is trusted for”

It is trusted to say who this person is. It is not trusted to say what they may do: the role comes from Tavrik’s own operator record, checked on every request against the three-role model (viewer, operator, root).

That split is why two further rules exist.

Accounts are not created automatically unless you turn that on. By default an operator must exist in Tavrik before single sign-on will admit them, so adding someone to a directory group does not silently grant them access to a governance tool. Where a hospital wants the convenience, auto-provisioning can be enabled and the role it assigns is restricted to viewer or operator.

The root role cannot sign in through single sign-on at all. Root is reserved for break-glass use with an API key. Someone who takes over your identity provider can therefore reach whatever roles you have granted, and cannot make themselves an administrator of the thing that is auditing them.

Sessions

Section titled “Sessions”

Sessions are short-lived and revocable. Disabling an operator invalidates their active sessions at the next request, and reducing someone’s role signs them out immediately, so a demotion takes effect rather than waiting for a token to expire.

What you need to provide

Section titled “What you need to provide”
  • An OIDC issuer or SAML metadata endpoint, and a client registration for the console.
  • A redirect URL, which onboarding gives you for your deployment.
  • A decision on auto-provisioning: off by default.