I am not sure if this is a bug, but rather may be a security limit placed by the OAuth protocol that you are implementing through FusionAuth. I will have to check to see if this pattern --- file:///... qualifies as an absolute URI.
In FusionAuth, the only valid redirects are outlined below.
An array of URLs that are the authorized redirect URLs for FusionAuth OAuth. Examples of valid redirect URIs: - https://example.com/redirect - com.myApp://redirect - com.myApp:/redirect AVAILABLE SINCE 1.7.0 You may now use URLs that do not begin with http to support native application redirect. Prior to this version the value will be validated to begin with http. AVAILABLE SINCE 1.12.0 You may now use URLs for application redirects that use a single slash to denote there is no naming authority for the scheme. Prior to this version a URL such as com.myApp:/redirect would fail validation as in invalid URL.https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2
From the OAuth spec
3.1.2. Redirection Endpoint
After completing its interaction with the resource owner, the
authorization server directs the resource owner's user-agent back to
the client. The authorization server redirects the user-agent to the
client's redirection endpoint previously established with the
authorization server during the client registration process or when
making the authorization request.The redirection endpoint URI MUST be an absolute URI as defined by
[RFC3986] Section 4.3. The endpoint URI MAY include an
"application/x-www-form-urlencoded" formatted (per Appendix B) query
component ([RFC3986] Section 3.4), which MUST be retained when adding
additional query parameters. The endpoint URI MUST NOT include a
fragment component.
