bdi-api is now a BDI Resource Server. It owns BDI snapshots, BDI history, BDI refresh jobs, scheduling, BDI-specific rate limits, and BDI persistence only.
Authentication issuing, refresh tokens, user management, password storage, and private signing keys were extracted to auth-api.
| Method | Path | Access | Purpose |
|---|---|---|---|
GET |
/api/v1/bdi/current |
USER, ADMIN |
Return the latest known BDI and freshness status |
GET |
/api/v1/bdi/history |
USER, ADMIN |
Return paginated BDI history |
POST |
/api/v1/admin/bdi/refresh |
ADMIN |
Start an asynchronous refresh job |
GET |
/api/v1/admin/bdi/refresh/{jobId} |
ADMIN |
Read refresh job status and result |
Removed endpoints now belong to auth-api:
POST /api/v1/auth/loginPOST /api/v1/auth/refreshPOST /api/v1/auth/logoutPOST /api/v1/admin/usersGET /api/v1/admin/usersGET /api/v1/admin/users/{id}PATCH /api/v1/admin/users/{id}
Configure JWT validation with:
bdi-api:
security:
jwt:
issuer: ${AUTH_JWT_ISSUER}
audience: ${AUTH_JWT_AUDIENCE:bdi-api}
jwks-uri: ${AUTH_JWKS_URI}MongoDB collections owned by bdi-api:
bdi_snapshotsbdi_refresh_jobs
Collections owned by auth-api:
usersrefresh_tokens
- Contract and bootstrap
- Domain and MongoDB
- BDI integration
- Asynchronous synchronization
- Original local security implementation
- REST API
- Rate limiting
- Delivery tooling
- Hardening and release
- Resource-server migration after auth extraction
- Missing token returns
401. - Token with wrong issuer returns
401. - Token with wrong audience returns
401. - Token with
USERrole can access BDI current/history. - Token with
USERrole cannot access BDI admin refresh. - Token with
ADMINrole can access BDI admin refresh. - Removed auth/user endpoints are absent from
bdi-api. - MongoDB integration tests cover only BDI-owned collections and indexes.
- Rate-limit tests cover only BDI and BDI administration policies.
./mvnw -Dkotlin.compiler.daemon=false clean verifypasses.