P1-3: JWT auth + OIDC (Entra ID / Google Workspace / Okta) for proxy clients
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 157
- Forks
- 32
- Avg merge
- 1h 25m
- Merged PRs (30d)
- 145
Description
Problem
Today proxy auth is `Authorization: Bearer <static_api_key>` only (`crates/aisix-proxy/src/auth.rs:1-139`). Enterprise customers using SSO need JWT verification — the bearer becomes an OIDC ID token signed by their IdP (Entra ID / Google Workspace / Okta / Auth0 / Keycloak / generic OIDC).
LiteLLM has full OIDC introspection; we have nothing.
Scope
DP (moonming/ai-gateway)
- Detect JWT format in the bearer (3-segment base64). If JWT shape, switch to JWT path; otherwise keep static-key path.
- Verify signature against JWKS (cached, refresh every `jwks_refresh_interval`).
- Validate `iss`, `aud`, `exp`, `nbf`. Optional: per-claim allowlist (e.g., `groups` claim must contain "ai-users").
- Map verified JWT to a virtual ApiKey-equivalent identity carrying the JWT's `sub` as the rate-limit/budget key. Optional: pre-provision `Identity` records keyed by sub for per-user budgets/limits.
- Config (etcd-loaded): `auth.jwt: { providers: [{name, jwks_url, issuer, audience, claim_mappings}] }`.
CP (api7/api7ee-3-control-plane)
- New resource `auth_provider` (env-scoped) with kind=`jwt` config.
- CRUD endpoints + push to etcd.
Dashboard UI (api7/AISIX-Cloud)
- New page "Auth providers" under Environment scope.
- Form: provider type (Entra/Google/Okta/Auth0/generic), wizard prefilling JWKS URLs from well-known IdP discovery docs.
e2e
- Mock JWKS endpoint, sign a JWT, send to DP, assert auth succeeds.
- Negative test: tampered JWT signature → 401.
Estimate
DP 4d, CP 1.5d, UI 2d, e2e 1d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading crates/aisix-proxy/src/auth.rs:1-139 and the existing etcd-loaded authentication configuration. Then trace the control-plane and dashboard authentication-provider entry points, and review the e2e setup for mock services. Done means static bearer keys still work, configured OIDC tokens are verified and mapped correctly, CRUD/configuration flows work, and both positive and tampered-signature tests pass.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- authentication, backend-api-design, frontend, security, testing-qa
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100