Skip to content

Release v2.30.0

Choose a tag to compare

@github-actions github-actions released this 02 Oct 07:57
5c431fe

Summary

Services can declare bearer routes such as /mcp and /v1 that accept access tokens from an external authorization server and forward the same trusted identity headers as browser sessions. AuthProxy remains an edge and relying party; it does not issue these tokens.

Added

  • Bearer routes configured through Services:<name>:BearerRoutes[], with path prefixes, issuers, audiences, required scopes, protected-resource metadata URLs, tenant claims, identity providers and claim mappings. The deployment's proxy-wide and service Authorization.RequiredClaims apply to bearer-token principals after claim mappings; a route can add its own RequiredClaims and set IgnoreDeploymentRequiredClaims to leave the deployment's requirements out, which is logged at startup. Invalid route configuration stops AuthProxy at startup, including resource-metadata paths at or below any bearer-route prefix, bearer routes on a service with StripPathPrefix, and bearer prefixes that overlap another service's PathPrefix on any host. Surrounding whitespace in configured issuer identifiers and tenant claim names is trimmed. (#143)
  • Access-token validation with exact issuer and metadata matching, JWKS signature verification, RS256 or ES256, an issuer-configured access-token typ (at+jwt and application/at+jwt by default), exact route audiences (a trailing slash names a different audience), required expiry and a single subject. Encrypted, unsigned and HMAC tokens are refused. (#143)
  • Cached issuer keys, with rate-limited unknown-key refresh awaited by the requesting caller before validation is retried. Automatic refreshes run in the background while ordinary callers use cached keys. Failed metadata retrieval backs off for 30 seconds, including before the first success, and preserves previously trusted keys during an outage. (#143)
  • Tenancy read only from the route's tenant claim (tid by default); a missing usable tenant gives 403. Claim mappings cannot overwrite the tenant claim or declare targets differing only by case, and mapped identity fields must be single-valued. (#143)
  • API-style refusals: 401 with resource_metadata or invalid_token, 403 for insufficient scope or denied access, 400 for ambiguous paths (%, \, ;, repeated / separators or dot segments), and 503 when trusted issuer keys are unavailable. Refusals, including unsupported methods on resource-metadata paths, are no-store. (#143)
  • Forwarded x-cratis-token-scope and x-cratis-token-client-id headers, plus bearer-route configuration and authentication guides with a Direct example. (#143)
  • Bearer requests honor the backend, service and root ActivityTimeout settings in that order, falling back to five minutes and applying configuration reloads to subsequent requests. (#143)

Changed

  • Bearer routes use tokens alone, never browser sessions or interactive redirects. Tokens naming a bearer-route issuer are refused on other routes regardless of Authorization casing or whitespace. (#143)
  • Bearer routes strip inbound identity, tenant and token headers, never forward cookies, and forward Authorization only when configured. Role claims in any casing are dropped; mappings replace all case variants of their targets, and forwarded JWT identity fields use exact claim names. (#143)
  • Bearer routes never call /.cratis/me; backends must enforce tenant membership. A startup warning explains this, and deployments requiring identity verification must set AcceptWithoutIdentityVerification: true on each bearer route to accept its callers without that verification. Identity verification is required by default for services with backends that participate in identity resolution. (#143)
  • Browser sessions no longer forward claims in the urn:cratis:bearer: namespace or inbound x-cratis-token-scope and x-cratis-token-client-id headers, which only bearer routes set, even in deployments without bearer routes. (#143)
  • When bearer routes are configured, ambiguous paths are rejected before route selection instead of falling through to browser sessions, including aliases such as /api//mcp/tools for /api/mcp. Clients must send unambiguous paths; see the bearer-route path rules. (#143)