Skip to content

fix(client): apply every mTLS endpoint alias, whatever the reason for mutual TLS - #552

Merged
osanderson merged 1 commit into
mainfrom
fix/mtls-aliases-all-endpoints
Oct 4, 2026
Merged

osanderson merged 1 commit into
mainfrom
fix/mtls-aliases-all-endpoints

Conversation

@osanderson

Copy link
Copy Markdown
Collaborator

Summary

What RFC 8705 §5 requires. A client "intending to do mutual TLS (for OAuth client authentication and/or to acquire or use certificate-bound tokens) when making a request directly to the authorization server MUST use the alias URL of the endpoint within the mtls_endpoint_aliases, when present."

client.MTLSEndpoints split the aliases by purpose instead, and each helper missed one endpoint:

Helper Moved Missed
ApplyForClientAuth Token, PAR, revocation CIBA backchannel authentication. CIBA Core §7.1 requires the client to authenticate there with its registered method, so a certificate-authenticated CIBA client sent its request to the plain endpoint.
ApplyForSenderConstrain Token, CIBA, revocation PAR

The fix:

  • Both helpers now apply every advertised alias (token, PAR, backchannel authentication and revocation) through one shared function.
  • The authorization endpoint is never aliased, because the browser calls it, not the client.
  • Callers keep calling whichever helper they did. A client doing both kinds of mTLS needs only one call.
  • The mTLS guide's snippet and the conformance client's comment are updated to match.

This follows #550, which fixed the revocation case of the same split.

Verification

  • Test: a new test runs both helpers and expects every alias applied, with the authorization endpoint untouched. The nil-receiver and partial-alias tests are unchanged.
  • Mutation checks: dropping any one of the four aliases makes the test fail.
  • Builds and suite: go vet, the full test suite, golangci-lint, the conformance client's build and the payroll-run demo's build are all clean.
  • Conformance: the full suite is being run against this branch. Its mTLS configurations exercise servers with and without aliases.

🤖 Generated with Claude Code

… mutual TLS

RFC 8705 §5: a client "intending to do mutual TLS (for OAuth client
authentication and/or to acquire or use certificate-bound tokens) when
making a request directly to the authorization server MUST use the
alias URL of the endpoint", wherever the server advertises one.

MTLSEndpoints split the aliases by purpose instead. ApplyForClientAuth
moved Token, PAR and revocation, but not the CIBA backchannel
authentication endpoint, where CIBA Core §7.1 requires the client to
authenticate with its registered method, so a certificate-authenticated
CIBA client sent its request to the plain endpoint.
ApplyForSenderConstrain moved Token, CIBA and revocation, but not PAR.

Both now apply every advertised alias (Token, PAR, backchannel
authentication and revocation), the same way; Authorization, which the
user agent calls, is never aliased. Callers keep calling whichever they
did; a client doing both needs one call. The mTLS guide and the
conformance client's comment say so.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@codecov

codecov Bot commented Oct 4, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@sonarqubecloud

sonarqubecloud Bot commented Oct 4, 2026

Copy link
Copy Markdown

@osanderson
osanderson merged commit d8b4e79 into main Oct 4, 2026
17 of 18 checks passed
@osanderson
osanderson deleted the fix/mtls-aliases-all-endpoints branch October 4, 2026 12:57
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.

1 participant