Allow RFC 8252 loopback port flexibility for registered redirect URIs
Preflight Checklist
- I agree to follow the Code of Conduct that this project adheres to.
- I have searched the issue tracker for an issue that matches the one I want to file, without success.
Problem Description
A public client cannot currently use both an ephemeral-port loopback redirect and a fixed redirect, i.e. the RFC 8252 native-app flow and the a server-side web callback.
Citing RFC 8252 7.3:
The authorization server MUST allow any port to be specified at the time of the request for loopback IP redirect URIs, to accommodate clients that obtain an available ephemeral port from the operating system at the time of the request.
There is a test case currently implemented that shows this is deliberate behavior, i.e. an explicitly configured URL does stop ephemeral-port loopback to be valid:
Proposed Solution
Extend the validation logic for loopback URLs to not match the port. Maybe follow §8.3 and do this only for IP literals, i.e. 127.0.0.1 / [::1].
I could work on a PR for this if you are interested.
Alternatives Considered
No response
Additional Information
This is a breaking change for loopback IP literals. However, this is probably not used much in combination with other URLs due to the port limitation.
Source: dexidp/dex