Skip to main content

​
Identity Provider Posture

​
Summary (3–6 bullets)

  • Documents the current authentication and identity-provider posture for production.
  • Clarifies what is implemented now versus planned (GCIP/Identity Platform).
  • Defines JWT authority and org-scoping behavior used by backend APIs.
  • Provides decision guardrails for any future migration to managed identity.

​
When to use this (3–6 bullets)

  • During auth architecture reviews.
  • Before changing login/JWT issuance or org-scoping logic.
  • During security incident triage involving token claims.
  • When evaluating GCIP/Identity Platform adoption.

​
What you’ll walk away with (2–5 bullets)

  • A clear statement of current-state identity architecture.
  • Constraints that must remain true for tenant/org isolation.
  • A checklist for safely introducing managed identity later.

​
Current posture (active)

​
Implemented

  • JWT-based API authentication is active.
  • tenant_id claim is mandatory for tenant isolation.
  • role governs route-level RBAC enforcement.
  • org_id authority model:
    • If JWT contains org_id, it is authoritative.
    • If JWT does not contain org_id (platform admin), X-Org-Id is required for org-scoped operations.

​
Not implemented as active platform standard

  • GCIP / Google Identity Platform is not documented as the current production identity control plane in active docs.
  • No active runbook currently defines managed IdP federation as the required auth source of truth.

​
Security invariants

  • Never trust client-provided tenant context over JWT claims.
  • Enforce server-side RBAC before sensitive data queries.
  • Fail closed on missing/invalid claims for protected operations.
  • Preserve strict tenant and org scoping in both API and query layers.

​
Decision posture for future GCIP adoption

If GCIP is introduced, require all of the following before cutover:
  • Token issuer/audience verification spec finalized
  • Claim mapping contract (tenant_id, role, org_id, agent_id) finalized
  • Backward compatibility and migration plan for existing JWT consumers
  • End-to-end auth smoke tests across admin/agent/ceo roles
  • Incident rollback path documented and rehearsed
Until then, treat current JWT-based auth as canonical runtime behavior.