fix(server): native-redirect review fixes before v0.44.0

[osanderson]

Summary

These are the fixes from the security and DevX review of #524 (native-app redirect URIs), before v0.44.0. There are four commits, for release-please.

fix(server): BuildAuthorizationErrorRedirect skipped the redirect policy (Low regression, both reviews found it).

• Cause: feat(server): accept native-app redirect URIs for clients registered as native #524 parsed every authorization response permissively when building it, assuming PAR had already held redirect_uri to the client's type. BuildAuthorizationErrorRedirect never goes through PAR; it only checked that the URI was registered.
• Effect: under production assurance, a web client registered for http://127.0.0.1/callback, http://localhost/callback or a private-use URI got an error redirect there, carrying error and state. FAPI 2.0 forbids that, and v0.43.0 refused it.
• Severity: it isn't an open redirect, since the destination is always one of the client's own registered URIs.
• Fix: the method now applies parseRedirectURI(client, …), as PAR does.

PAR's refusal of a native URI on a client registered as web now names ApplicationTypeNative in its cause (for logs, never the response). That's the first mistake a wallet integrator makes.

fix: stricter native URI forms and clearer messages.

• Empty authority: private-use URIs with one (com.example.app:///cb, :////host/cb) are refused. The error shows the single-slash form RFC 8252 §7.1 writes: com.example.app:/callback, not com.example.app://callback.
• Strict loopback literal: a native loopback URI must be exactly 127.0.0.1 or ::1; net.IP.Equal also accepted the IPv4-mapped ::ffff:127.0.0.1.
• Clearer host message: ParseIssuerURL and ParseEndpointURL now say a hostless URI "must have a host" instead of the misleading "must be absolute".

feat(storage): ApplicationType.String/IsValid and ParseApplicationType for the "web"/"native" wire values, matching ClientAuthMethod and SenderConstrain.

docs: several docs said loopback http redirects are development-only. That's the web client's rule, so I updated the native exceptions in:

• server/assurance.go;
• AllowLoopbackHTTP, URLOption, AllowPrivateUseScheme, ApplicationTypeNative and HasRedirectURI;
• ARCHITECTURE and GETTING_STARTED.

GETTING_STARTED now shows the single-slash form and corrects "a web client can use neither" (it can use loopback under development). README lists native apps and RFC 8252.

Deferred: per-authorization redirect URIs in the FAPIgo client, for a desktop wallet that binds a new port each flow. One *client.Client per listener works today.

Tests

• TestBuildAuthorizationErrorRedirectHoldsTheRedirectPolicy (production): web clients with loopback, localhost or private-use URIs are refused; native clients with private-use or loopback URIs are accepted.
• TestPARNamesTheNativeRegistration: the cause names ApplicationTypeNative for a native URI on a web client, and doesn't for a URI no registration admits.
• TestParseRedirectURL and TestParseRedirectURLSaysWhatToChange:
  • :/// and :////host are refused;
  • the two-slash error shows com.example.app:/path;
  • the no-host error doesn't say "must be absolute".
• Storage:
  • TestNativeRedirectURIsAtRegistration gains the [::ffff:127.0.0.1] refusal.
  • TestApplicationTypeWireValues round-trips "web" and "native" and refuses "", "Native" and "mobile".
• Mutation checks:
  • unchecking the error redirect fails a test;
  • dropping the native hint fails a test;
  • allowing an empty authority fails a test;
  • allowing IPv4-mapped loopback fails a test.
• Other checks:
  • go test -race across fapi, storage, server, federation and client passes.
  • go test ./cmd/... ./fapitest/... passes.
  • Every demo's tests pass.
  • FuzzParseRedirectURL (15 seconds) is clean.
  • golangci-lint is clean.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud