feat: exact redirect_uri matching via --redirect-uris - #786
Merged
Conversation
A client that registered its redirect URIs - through RFC 7591 or a metadata document - has always been held to an exact match. The deployment's own client could not be: it is seeded into the registry at boot and nothing writes RedirectURIs to that row, so it always fell through to the --allowed-origins check, which compares ORIGINS. Every path under an allowed origin was a valid redirect target. OIDC Core 3.1.2.1 and RFC 6749 3.1.2.3 both require an exact match; the OpenID Foundation suite fails oidcc-ensure-registered-redirect-uri and oidcc-ensure-request-object-with-redirect-uri on the origin behaviour. Read from config rather than the registry row on purpose: writing it at boot would need UpdateClient to carry the field across every storage backend, and would leave a stale allow-list behind the day an operator removes the flag. The flag is then the whole state. Unset keeps the origin fallback. Making exact matching the default would refuse the callback of every deployment that never listed its URIs. Entries that could never match - no scheme, a fragment, user info - are refused at startup rather than at every login, where the flag would look configured and nothing would name the entry at fault.
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
1 participant
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.
Closes the OIDC Core §3.1.2.1 gap the conformance run found.
The gap
A client that registered its redirect URIs — through RFC 7591 registration or a metadata document — has always been held to an exact match. The deployment's own client (named by
--client-id) could not be: it is seeded into the registry at boot and nothing writesRedirectURIsto that row, socheckClientRedirectURIalways fell through toIsValidRedirectURI(uri, AllowedOrigins, host), which compares origins.Probed against 2.4.0:
The OpenID Foundation Basic profile fails
oidcc-ensure-registered-redirect-uriandoidcc-ensure-request-object-with-redirect-urion exactly this.The fix
--redirect-uris, a comma-separated list of exact URIs for that client. When set, the same comparison registered clients already get applies — including the RFC 8252 §7.3 loopback-port carve-out. When unset, nothing changes.Read from config rather than written to the registry row: persisting it would need
UpdateClientto carry the field across every storage backend, and would leave a stale allow-list behind the day an operator removes the flag.Not the default. Exact matching as the default would refuse the callback of every deployment that never listed its URIs.
Verified
make test44 pkgs,make lint0 issues,make smoke— all pass