Skip to content

feat(auth): add RFC 9728 OAuth Protected Resource Metadata support - #5294

Open
visit2rahul wants to merge 5 commits into
apache:mainfrom
visit2rahul:feat/oauth-protected-resource-metadata-2581
Open

feat(auth): add RFC 9728 OAuth Protected Resource Metadata support#5294
visit2rahul wants to merge 5 commits into
apache:mainfrom
visit2rahul:feat/oauth-protected-resource-metadata-2581

Conversation

@visit2rahul

@visit2rahul visit2rahul commented Aug 15, 2026

Copy link
Copy Markdown
Contributor

Quarkus 3.25+ has built-in support for RFC 9728 (OAuth 2.0 Protected Resource Metadata). When enabled it serves `/.well-known/oauth-protected-resource`, which lets catalog clients auto-discover the authorization server URL from the catalog URI instead of requiring it in their config.

This wires it up for Polaris: adds the `quarkus.oidc.resource-metadata.*` properties to `application.properties` next to the existing OIDC block (including the `authorization-server` override), and a `@QuarkusTest` that enables the feature with OIDC discovery disabled so no live auth server is needed, then verifies the endpoint returns the expected `authorization_servers` value.

Closes #2581

@adutra please review and lmk your thoughts. thanks!

Polaris already uses Quarkus 3.25+ which includes built-in support for
the OAuth 2.0 Protected Resource Metadata specification (RFC 9728) via
OidcTenantConfig.ResourceMetadata / ResourceMetadataHandler. When
enabled, Quarkus serves /.well-known/oauth-protected-resource so that
catalog clients can auto-discover the authorization server URL from the
catalog URI without requiring explicit client-side configuration.

Wire this up by documenting the relevant Quarkus properties in
application.properties (quarkus.oidc.resource-metadata.*) and adding a
@QuarkusTest that exercises the endpoint end-to-end: the test enables
the OIDC tenant, disables discovery (no live auth server needed), and
verifies that the well-known response carries the configured
authorization_servers value.

Closes apache#2581

Signed-off-by: Rahul Joshi <visit2rahul@gmail.com>
When discovery-enabled=false, Quarkus TenantContextFactory requires
either jwks-path or introspection-path to be set or throws
ConfigurationException at startup. The JWKS endpoint is never
fetched by the test since /.well-known/oauth-protected-resource
is unauthenticated.

Signed-off-by: Rahul Joshi <visit2rahul@gmail.com>
Without resolve-early=false, Quarkus eagerly fetches JWKS from the
test auth-server-url at startup. The fetch fails, leaving the tenant
"not ready" so ResourceMetadataHandler never registers the
/.well-known/oauth-protected-resource route.

Setting jwks.resolve-early=false defers the fetch to the first
authenticated request. Since the endpoint under test is public, JWKS
are never needed and the tenant becomes ready at startup.

Signed-off-by: Rahul Joshi <visit2rahul@gmail.com>
…a handler

Quarkus's ResourceMetadataHandler does not set Content-Type on the
response -- it writes the JSON body and ends the response directly.
Assert only on status and body fields.

Signed-off-by: Rahul Joshi <visit2rahul@gmail.com>
…pendency

Quarkus's ResourceMetadataHandler does not set Content-Type on the
response. RestAssured's JSONPath body matchers require a content-type
header to select a parser; without one they throw IllegalStateException.

Extract the body as a string and parse it with JsonPath.from() directly
so the assertions are independent of the response content-type.

Signed-off-by: Rahul Joshi <visit2rahul@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support for OAuth Protected Resource Metadata (RFC 9728)

1 participant