ADR-07: OIDC for authentication

Context

TINO needed an authentication mechanism. The options were: local auth (username/password with its own user store), LDAP, or SSO via OpenID Connect.

Decision

TINO delegates authentication entirely to an external OpenID Connect provider (e.g. Keycloak). The OIDC callback establishes a signed server-side session cookie. Group claims from the ID token drive bucket-level access control.

Authentication can be disabled entirely via TINO_AUTH_DISABLED for local development or trusted internal deployments.

Consequences

Positive

  • No user management
    TINO has no user database, no password storage, and no account lifecycle to manage — all of that lives in the identity provider.
  • SSO out of the box
    Users who are already signed into the OIDC provider get seamless access.
  • Group-based access control
    OIDC group claims map directly to bucket roles, making access policy a configuration concern rather than an application concern.
  • Secure by delegation
    MFA, password policy, and session management are handled by a dedicated, audited identity system.
  • De-facto standard
    OIDC is the standard authentication protocol for most enterprises and cloud platforms.
    Chances are the identity provider is already in place and TINO just plugs in.

Negative

  • External dependency
    A production deployment requires a running OIDC provider.
    This adds operational complexity for teams that do not already have one.
  • Provider-specific claims
    Group claim names vary between providers (e.g. Keycloak vs Azure AD).
    The claim key must be configured via TINO_OIDC_GROUPS_CLAIM.