v0.1.26

What's Changed

• Styled 401 Unauthorized and 404 error pages to match the landing page design (Inter/JetBrains Mono fonts, warm background, consistent branding)
• Added shared _ERROR_PAGE_STYLE for consistent styling across all error pages
• 401 pages now show the specific authentication error detail in a styled box
• Custom Falcon error serializer renders HTML for 401 responses

v0.1.25

What's Changed

• Support custom X-VGI-Accept-Encoding and X-VGI-Content-Encoding headers for zstd compression, to bypass proxies/CDNs that strip standard Content-Encoding headers

v0.1.24

What's Changed

• Improved OAuth validation errors: OAuthResourceMetadata validation errors now include the offending value for easier debugging
• JWT diagnostic logging: jwt_authenticate now logs expected vs actual claims (issuer, audience) when JWT validation fails, aiding troubleshooting of auth misconfiguration

v0.1.23

What's Changed

• Support multiple audiences in jwt_authenticate: The audience parameter now accepts str | tuple[str, ...], allowing tokens from either client_id or device_code_client_id (which may use different audiences) to be validated by a single authenticator. Uses Authlib's "values" key for native multi-audience support — no decode loop needed. Empty tuple raises ValueError eagerly.

v0.1.22

What's New

• Add device_code_client_id and device_code_client_secret to OAuth Resource Metadata for OAuth providers that require separate credentials for the device code grant flow

v0.1.21

What's Changed

• Add use_id_token_as_bearer boolean field to OAuth Resource Metadata (OAuthResourceMetadata, OAuthResourceMetadataResponse, WWW-Authenticate header)
• Add parse_use_id_token_as_bearer() helper for extracting the flag from WWW-Authenticate headers

When use_id_token_as_bearer=True, clients are told to use the OIDC id_token as the Bearer token instead of the access_token. This is a custom extension (not defined in RFC 9728) following the same pattern as client_id and client_secret.

v0.1.20

What's Changed

• Add client_secret to OAuth Resource Metadata (OAuthResourceMetadata, OAuthResourceMetadataResponse, WWW-Authenticate header)
• Add parse_client_secret() helper for extracting client_secret from WWW-Authenticate headers
• Reduce .well-known/oauth-protected-resource cache max-age from 3600s to 60s

Google requires client_secret in OAuth resource metadata even when using PKCE. The client_secret follows the same pattern as client_id — it appears in the well-known JSON document, the WWW-Authenticate challenge header, and is discoverable via http_oauth_metadata().

v0.1.19

What's New

• OAuth client_id support: Added optional client_id field to OAuthResourceMetadata and OAuthResourceMetadataResponse as a custom RFC 9728 extension for MCP compatibility
  • Serialized in /.well-known/oauth-protected-resource JSON and WWW-Authenticate headers on 401 responses
  • New parse_client_id() helper to extract client_id from WWW-Authenticate headers
  • URL-safe character validation on client_id values

v0.1.18

What's Changed

• Bearer token authentication — bearer_authenticate, bearer_authenticate_static, and chain_authenticate factories for composing HTTP auth callbacks
• Mutual TLS (mTLS) authentication — client certificate auth via proxy-forwarded headers:
  • mtls_authenticate — generic factory with custom certificate validation
  • mtls_authenticate_fingerprint — certificate fingerprint lookup
  • mtls_authenticate_subject — Subject CN extraction with optional allowlist
  • mtls_authenticate_xfcc — Envoy x-forwarded-client-cert header parsing (no extra deps)
• New vgi-rpc[mtls] optional dependency (cryptography) for PEM-based factories
• Documentation for mTLS authentication with proxy configuration examples (nginx, AWS ALB, Envoy)

v0.1.17

What's Changed

• Add GitHub artifact attestations and PyPI attestations to publish workflow
• Skip README runnable examples on Windows CI (subprocess transport unreliable)
• Consumers can verify build provenance with gh attestation verify