Token Signing Unavailable

URI: https://docs.ankatech.co/errors/token-signing-unavailable
HTTP Status: 503 Service Unavailable

When you see this

auth-api holds no usable user-token signing key set, so it can neither issue a token nor publish the JWK Set. There is no fallback key. It is answered in these places:

• POST /api/v3/auth/token, every grant — password, client_credentials, refresh_token and token-exchange. The refusal runs after request validation and before the grant examines its credential, so a valid and an invalid credential get the same answer, and nothing is examined or moved: no admin-api call, no lockout count, no refresh token consumed or rotated, no impersonation validated. A refresh token presented during the outage still works afterwards.
• GET /api/v3/auth/.well-known/jwks.json — no set is published, never an empty keys array, and the answer is application/problem+json whatever the Accept.
• Token introspection and logout, when the submitted access token has to be verified and no set is held to verify it with: nothing was decided about the token, so the answer is neither active: false nor a revocation that did not happen.

Federated sign-in is also refused before it provisions anything, but on the browser-redirect surface (see Federated Login Errors), not with this problem.

Common Causes

• auth-api could not resolve its signer projection from admin-api's custody (admin-api or its custody root unreachable).
• The resolved projection was refused as unsound.
• The projection auth-api holds is past its stale bound and could not be refreshed.

Response Example

HTTP/1.1 503 Service Unavailable
Content-Type: application/problem+json
Retry-After: 30

{
  "type": "https://docs.ankatech.co/errors/token-signing-unavailable",
  "title": "Token Signing Unavailable",
  "status": 503,
  "detail": "The token signing key set is temporarily unavailable; no token can be issued or published.",
  "instance": "/api/v3/auth/token",
  "timestamp": 1790503200
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.

The detail is constant: it names neither the custody key nor admin-api's address.

How to Resolve

1. Retry after Retry-After.
2. If it persists, check auth-api's readiness (the tokenSigningKeys contribution reports DOWN) and admin-api's health, and the admin-api answers described in Admin API — Platform Token Signing Keys^*.

See also Auth API — Token Signing JWK Set and Token Signing Key Set and Rotation.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.