Skip to main content

Auth And Access designed

GPUaaS uses an OIDC-first identity model with server-side authorization. API consumers should treat the public API contract and the project-scoped access model as the integration boundary, not internal identity-provider details.

Access Patterns​

ActorPreferred pathNotes
Human userOIDC browser or CLI loginUsed for interactive workflows and project administration.
AutomationProject-scoped service accountUsed for controllers, CI jobs, app operators, and backend integrations.
Future API key userDeferred contractAPI keys are a future extension; do not assume key endpoints until the contract lands.

Service Account Guidance​

Use service accounts when automation keeps running after a human deploy action. The intended shape is:

  1. A human project admin creates a project-scoped service account.
  2. The service account mints short-lived access tokens.
  3. Automation calls public GPUaaS APIs with the token.
  4. Authorization remains server-side and project-scoped.

Do not reuse human operator tokens for long-running controllers. Do not build against undocumented Keycloak topology, raw JWT claim conventions, or direct database state.

Login And Project Context​

Service Account Token Flow​

Client Expectations​

  • Send bearer credentials only through approved auth channels.
  • Treat tenant, project, user, and service-account boundaries as enforced by the platform.
  • Use documented scopes and roles, not frontend-only assumptions.
  • Preserve correlation_id from error responses for support and trace lookup.
  • Expect future API-key support to be additive and contract-backed.
Canonical sources