feat(authserver): add OAuth 2.0 client_credentials grant support for M2M clients

[RobertWi]

Summary

Add client_credentials grant type support to ToolHive's built-in OAuth authorization server, enabling machine-to-machine (M2M) authentication as recommended by the MCP specification (2025-03-26).

Motivation

The MCP spec explicitly recommends client_credentials for non-human clients:

MCP servers SHOULD support the OAuth grant types that best align with the intended audience. For instance:

1. Authorization Code: useful when the client is acting on behalf of a (human) end user.
2. Client Credentials: the client is another application (not a human)

PR #3425 correctly blocked client_credentials in DCR because the server couldn't fulfill it at the time. This PR implements the capability, then updates the allowlist.

Changes

Production code (5 files, ~100 lines)

• server_impl.go: Wire OAuth2ClientCredentialsGrantFactory into fosite composition (1 line)
• registration/dcr.go: Support confidential client registration — redirect_uris optional for client_credentials-only clients, client_secret_basic/client_secret_post auth methods accepted, secret generation
• handlers/dcr.go: Generate and return client_secret for confidential clients in DCR response
• handlers/token.go: Populate session subject with client ID for client_credentials grants so JWT has meaningful sub claim
• handlers/discovery.go: Advertise client_credentials grant and client_secret_basic/client_secret_post in OAuth AS + OIDC discovery metadata

Storage / Authorization

No changes needed. The existing storage interface already satisfies fosite's requirements for client_credentials. Cedar authorization naturally handles Client:: principals derived from the sub claim.

Tests (5 files, ~340 lines)

• Updated DCR validation tests: flipped client_credentials rejection cases to success, added 6 new confidential client test cases
• Updated token handler tests: fixed unsupported grant type test, added 3 new client_credentials tests (success, wrong secret, resource parameter)
• Updated discovery tests: added client_credentials + auth method assertions
• Added 3 integration tests: basic flow with JWT claim validation, RFC 8707 audience binding, wrong secret rejection

Test Evidence

Full test suite with race detector — all 10 authserver packages pass:

$ go test ./pkg/authserver/... -count=1 -race

ok  	github.com/stacklok/toolhive/pkg/authserver	5.844s
ok  	github.com/stacklok/toolhive/pkg/authserver/runner	1.350s
ok  	github.com/stacklok/toolhive/pkg/authserver/server	1.666s
ok  	github.com/stacklok/toolhive/pkg/authserver/server/crypto	2.011s
ok  	github.com/stacklok/toolhive/pkg/authserver/server/handlers	7.307s
ok  	github.com/stacklok/toolhive/pkg/authserver/server/keys	1.360s
ok  	github.com/stacklok/toolhive/pkg/authserver/server/registration	3.573s
ok  	github.com/stacklok/toolhive/pkg/authserver/server/session	1.178s
ok  	github.com/stacklok/toolhive/pkg/authserver/storage	3.477s
ok  	github.com/stacklok/toolhive/pkg/authserver/upstream	2.098s

New tests added by this PR — all pass:

--- PASS: TestIntegration_ClientCredentials_BasicFlow (0.20s)
--- PASS: TestIntegration_ClientCredentials_WithAudience (0.20s)
--- PASS: TestIntegration_ClientCredentials_WrongSecret (0.34s)
--- PASS: TestTokenHandler_ClientCredentials_Success (0.17s)
--- PASS: TestTokenHandler_ClientCredentials_WrongSecret (0.15s)
--- PASS: TestTokenHandler_ClientCredentials_WithResource (0.15s)

go vet ./pkg/authserver/... — clean, no findings.

Backward Compatibility

Fully backward compatible. Existing public client registrations and authorization_code flows are unaffected:

• defaultGrantTypes for empty DCR requests remain ["authorization_code", "refresh_token"]
• Public client validation logic is unchanged (just moved into an else branch)
• All existing tests pass without modification (only the two tests that explicitly tested client_credentials rejection were updated)

Diff Stats

 10 files changed, 436 insertions(+), 65 deletions(-)