Repository navigation
Release v2.30.0
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 serviceAuthorization.RequiredClaimsapply to bearer-token principals after claim mappings; a route can add its ownRequiredClaimsand setIgnoreDeploymentRequiredClaimsto 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 withStripPathPrefix, and bearer prefixes that overlap another service'sPathPrefixon 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+jwtandapplication/at+jwtby 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 (
tidby 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_metadataorinvalid_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, areno-store. (#143) - Forwarded
x-cratis-token-scopeandx-cratis-token-client-idheaders, plus bearer-route configuration and authentication guides with a Direct example. (#143) - Bearer requests honor the backend, service and root
ActivityTimeoutsettings 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
Authorizationcasing or whitespace. (#143) - Bearer routes strip inbound identity, tenant and token headers, never forward cookies, and forward
Authorizationonly 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 setAcceptWithoutIdentityVerification: trueon 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 inboundx-cratis-token-scopeandx-cratis-token-client-idheaders, 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/toolsfor/api/mcp. Clients must send unambiguous paths; see the bearer-route path rules. (#143)