Skip to content

Authentication Modes

MaaS supports two authentication paths for accessing models. Both paths produce the same result — an authenticated identity that the gateway validates — but they differ in how the user obtains their token and which component validates it.

Mode 1: RHOAI Dashboard (Platform Gateway)

Users log in through the RHOAI Dashboard, which authenticates via OpenShift OAuth. The Dashboard's kube-auth-proxy handles the OAuth flow and produces an OpenShift access token.

User → RHOAI Dashboard → OpenShift OAuth → kube-auth-proxy
  → Dashboard UI → BFF → maas-api (mint API key)
  → User uses API key for inference

Token validation layer: Gateway / Authorino validates the API key via POST /internal/v1/api-keys/validate callback to maas-api.

What the admin configures:

  • Nothing MaaS-specific — authentication is handled by the platform (OpenShift OAuth + kube-auth-proxy)
  • API keys are minted through the Dashboard UI or BFF, bound to the user's OpenShift identity and groups
  • The user's group membership (from OpenShift) determines which subscriptions and models are accessible

When to use: Interactive access through the RHOAI web interface. This is the default path for data scientists using the MaaS Playground or managing API keys through the Dashboard.

Mode 2: Standalone OIDC Client (External IdP)

Users authenticate directly against an external identity provider (Keycloak, Entra ID, Okta) and present a JWT bearer token to the MaaS gateway. Authorino validates the JWT against the IdP's JWKS endpoint.

User → External IdP (Keycloak / Entra ID) → JWT token
  → MaaS Gateway → Authorino validates JWT via JWKS
  → maas-api (mint API key with OIDC identity)
  → User uses API key for inference

Token validation layer: Gateway / Authorino validates the JWT locally using cached JWKS keys from the IdP. The azp (authorized party) claim is checked against the configured clientId.

What the admin configures:

For AITenant-managed tenants (including the default tenant), configure OIDC on the AITenant CR:

apiVersion: maas.opendatahub.io/v1alpha1
kind: AITenant
metadata:
  name: models-as-a-service
  namespace: ai-tenants
spec:
  oidc:
    issuerUrl: "https://keycloak.example.com/realms/maas"
    clientId: maas-api
    ttl: 300
Field Description
issuerUrl OIDC issuer URL (must be HTTPS). Must serve .well-known/openid-configuration.
clientId OAuth2 client ID. Tokens must have azp claim matching this value.
ttl JWKS cache duration in seconds (default: 300, minimum: 30).

For unmanaged tenants (not backed by an AITenant), configure OIDC on the Tenant CR directly:

apiVersion: maas.opendatahub.io/v1alpha1
kind: Tenant
metadata:
  name: default-tenant
  namespace: models-as-a-service
spec:
  externalOIDC:
    issuerUrl: "https://keycloak.example.com/realms/maas"
    clientId: maas-api
    ttl: 300

When to use: Programmatic API access from CI/CD pipelines, external applications, or enterprise environments that federate identity through a central IdP rather than OpenShift OAuth.

How Both Modes Coexist

Both modes work simultaneously on the same gateway. The AuthPolicy generated by the MaaS controller accepts:

  1. OpenShift tokens — validated via Kubernetes TokenReview
  2. API keys (sk-oai-*) — validated via maas-api callback
  3. OIDC JWTs (when configured) — validated locally by Authorino against cached JWKS

The order of evaluation is determined by Authorino's authentication chain. A request succeeds if any authenticator matches. There is no conflict between modes — they use different token formats and different validation paths.

For the explicit priority order (API keys → OIDC → OpenShift TokenReview) and why OIDC must run before TokenReview, see External OIDC Configuration.

Validation Layers

What Where validated How
OpenShift bearer token Gateway / Authorino Kubernetes TokenReview API
API key (sk-oai-*) Gateway / Authorino → maas-api HTTP callback to /internal/v1/api-keys/validate
OIDC JWT Gateway / Authorino Local JWKS validation (cached from IdP)
Subscription + group authorization Gateway / Authorino → maas-api HTTP callback to /internal/v1/subscriptions/select
Token rate limiting Gateway / Kuadrant + Limitador WASM shim evaluates TokenRateLimitPolicy

IdP Configuration Requirements

For Mode 2 (standalone OIDC), the IdP must:

  • Serve /.well-known/openid-configuration over HTTPS at the issuerUrl
  • Include azp (authorized party) claim in issued tokens matching the configured clientId
  • Expose a JWKS endpoint for public key retrieval
  • Issue tokens with group claims if group-based authorization is needed (claim name depends on IdP configuration)

MaaS does not perform OAuth2 client authentication (no client_secret). It validates bearer tokens only. Client authentication and secret management are the IdP's responsibility.

Field Alignment (Tenant vs AITenant)

Configuration fields align between Tenant CR and AITenant CR:

Field Tenant CR path AITenant CR path Semantics
Issuer URL spec.externalOIDC.issuerUrl spec.oidc.issuerUrl OIDC discovery endpoint (HTTPS required)
Client ID spec.externalOIDC.clientId spec.oidc.clientId OAuth2 client ID for azp claim matching
JWKS TTL spec.externalOIDC.ttl spec.oidc.ttl Cache duration for JWKS keys (seconds)

Note

For AITenant-managed tenants, set OIDC on the AITenant CR. The controller propagates the configuration to the tenant's gateway AuthPolicy. The Tenant CR's externalOIDC field is ignored for AITenant-managed tenants.

See Also