fix(client): keep PAR off the mTLS alias for certificate-bound tokens alone - #553
Merged
Merged
Conversation
… alone
The previous change made MTLSEndpoints.ApplyForSenderConstrain move PAR
to its mtls_endpoint_aliases entry, reading RFC 8705 §5 as one rule for
every endpoint. FAPI 2.0 conformance testing reads it per request: an
alias applies to a request that itself does mutual TLS. A client that
authenticates with private_key_jwt and uses mutual TLS only for
certificate-bound tokens does none at PAR, and the conformance suite
refuses its PAR request over mutual TLS ("The PAR endpoint was called
over an mTLS secured connection, but this is not expected when using
private_key_jwt client authentication"), failing 19 of 21 relying-party
tests for that configuration.
ApplyForSenderConstrain is back to Token, the CIBA backchannel
authentication endpoint and revocation, leaving PAR at the conventional
endpoint. ApplyForClientAuth keeps the part of the previous change that
holds either way: a certificate-authenticated client does mutual TLS at
every request that authenticates it, so it moves Token, PAR, the CIBA
endpoint (CIBA Core §7.1) and revocation, a superset of
ApplyForSenderConstrain's. The test pins the PAR exclusion, and the mTLS
guide and the conformance client's comment describe the per-request
rule.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
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
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.



Summary
This fixes a regression from #552, found by the conformance run against that branch. #552 is on main but unreleased: release PR #551 (v0.48.1) should not be merged until this lands.
What went wrong. #552 made
ApplyForSenderConstrainmove PAR to itsmtls_endpoint_aliasesentry, reading RFC 8705 §5 as one rule for every endpoint. FAPI 2.0 conformance testing reads §5 per request instead: an alias applies to a request that itself does mutual TLS. Aprivate_key_jwtclient with certificate-bound tokens does no mutual TLS at PAR, and the suite refused its PAR request in 19 of 21 relying-party tests:The fix (per request):
ApplyForSenderConstrainApplyForClientAuthApplyForClientAuthnow also moves the CIBA endpoint, because a certificate-authenticated client does mutual TLS at every request that authenticates it.ApplyForClientAuthcovers everythingApplyForSenderConstraindoes, so a client doing both needs one call.Verification
ApplyForSenderConstrain(citing the suite's message), and the full set forApplyForClientAuth.go vet, the full test suite, golangci-lint and the conformance client's build are clean.🤖 Generated with Claude Code