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 (legacy Tenant CR, not backed by an AITenant -- deprecated, will be removed in a future release):

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:

OpenShift tokens — validated via Kubernetes TokenReview
API keys (sk-oai-*) — validated via maas-api callback
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 (Legacy Tenant vs AITenant)

Configuration fields align between the legacy Tenant CR and the current 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.