Add authserver configuration with validation and auto-generation #3472
+504
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR introduces the `Config` type for the OAuth authorization server, providing a pure configuration interface with full validation. The config supports signing keys via a `KeyProvider` interface (with auto-generation for development), HMAC secrets for opaque tokens (authorization codes and refresh tokens), sensible token lifespan defaults (1h access, 7d refresh, 10m auth code), and pre-registered OAuth client definitions supporting both public and confidential client types. Issuer URL validation enforces HTTPS per OIDC Core Section 3.1.2.1 and RFC 8414, with a localhost exception for development workflows. This configuration layer is consumed by the core `newServer()` implementation in the `auth-proxy-pr-11-core-authserver` branch, which creates the fosite-based OAuth 2.0 authorization server. The server calls `applyDefaults()` to fill in missing values and `Validate()` to ensure correctness before constructing the `AuthorizationServerParams` that configure the OAuth2 provider, handlers, and endpoints. The "just works" philosophy enables quick development startup with ephemeral secrets while warning about their limitations, and the config cleanly separates concerns: this layer handles what the server needs, while the server implementation handles how it delivers OAuth/OIDC functionality.
jhrozek
commented
Jan 27, 2026
jhrozek
commented
Jan 27, 2026
jhrozek
commented
Jan 27, 2026
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3472 +/- ##
==========================================
+ Coverage 64.88% 65.12% +0.23%
==========================================
Files 396 400 +4
Lines 38512 39006 +494
==========================================
+ Hits 24990 25403 +413
- Misses 11572 11635 +63
- Partials 1950 1968 +18 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
tgrunnagle
reviewed
Jan 28, 2026
tgrunnagle
previously approved these changes
Jan 28, 2026
The Clients field and ClientConfig type were validated but never actually used to register OAuth clients with storage. The server relies entirely on Dynamic Client Registration (DCR) for client registration. Removing this dead code per PR review feedback. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Refactors the authserver Config to use a slice of UpstreamConfig instead of a single Upstream pointer. This prepares for future multi-upstream IDP support while currently validating that exactly one upstream is configured. Changes: - Add UpstreamConfig type with Name and Config fields - Change Upstream field to Upstreams slice - Add GetUpstream() helper for current single-upstream code paths - Add validateUpstreams() with uniqueness and count validation - Update tests for new structure Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Adds two new fields for MCP specification compliance: - ScopesSupported: OAuth 2.0 scopes advertised in discovery documents, defaults to ["openid", "offline_access"] - AllowedAudiences: Valid resource URIs for RFC 8707 resource parameter validation, required for MCP compliance AllowedAudiences is validated as non-empty since MCP clients MUST include the resource parameter per specification. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
jhrozek
requested review from
ChrisJBurns,
JAORMX,
dmjb and
yrobla
as code owners
github-actions
bot
added
size/M
tgrunnagle
approved these changes
Jan 28, 2026
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces the
Configtype for the OAuth authorization server, providing a pure configuration interface with full validation. The config supports signing keys via aKeyProviderinterface (with auto-generation for development), HMAC secrets for opaque tokens (authorization codes and refresh tokens), sensible token lifespan defaults (1h access, 7d refresh, 10m auth code), and pre-registered OAuth client definitions supporting both public and confidential client types. Issuer URL validation enforces HTTPS per OIDC Core Section 3.1.2.1 and RFC 8414, with a localhost exception for development workflows.This configuration layer is consumed by the upcoming
newServer()implementation which creates the fosite-based OAuth 2.0 authorization server. The server callsapplyDefaults()to fill in missing values andValidate()to ensure correctness before constructing theAuthorizationServerParamsthat configure the OAuth2 provider, handlers, and endpoints. The "just works" philosophy enables quick development startup with ephemeral secrets while warning about their limitations, and the config cleanly separates concerns: this layer handles what the server needs, while the server implementation handles how it delivers OAuth/OIDC functionality.