feat(endpoint-auth): validate cross-host redirect_uri against client_id

[rmdes]

Problem

validateRedirect only compares hosts, with the rest of the specification
left as a @todo:

// @todo If redirect URIs doesn’t share same host as `client_id`, validate
// against list of redirect URIs fetched from `<link>` tags or `Link` HTTP
// headers with a `rel` attribute of `redirect_uri` at the `client_id` URL.
export const validateRedirect = (redirectUri, clientId) => {
  return new URL(redirectUri).host === new URL(clientId).host;
};

Because the cross-host branch was never implemented, any client whose
callback lives on a different host to its client_id is rejected with
"Invalid value provided for redirect_uri", even when that client
correctly declares the URI as the spec requires.

Browser extensions are the case people actually hit. The browser issues the
redirect host, and it can never equal the client's own host:

Browser	Redirect host
Chrome / Edge / Vivaldi	<extension-id>.chromiumapp.org
Firefox	<uuid>.extensions.allizom.org

So no browser-extension IndieAuth client can complete a login against
Indiekit today. This was reported by a user signing in to their own server
(beta 28) from Firefox; it reproduces identically in Chrome.

What this does

Implements the @todo. When hosts differ, fetch client_id and collect the
redirect URIs it declares, via <link rel="redirect_uri"> tags and Link
HTTP headers, then match the request against them.

• HTML is parsed with microformats-parser, already a dependency of this
  package and already used by client.js. It exposes rels.redirect_uri
  directly and resolves relative hrefs against the base URL, so
  href="/callback" works. No new dependencies.
• Link headers are parsed for values whose rel includes
  redirect_uri, handling quoted and unquoted forms and multi-value rel.
• Fails closed. A network error, non-2xx response or unparseable markup
  yields no declared URIs, so nothing matches. Fetches time out after 5s.
• Same-host requests keep the existing fast path and never trigger a fetch.

Subdomain wildcards — the part worth discussing

A declared URI may replace its left-most host label with *.:

<link rel="redirect_uri" href="https://*.chromiumapp.org/">

This isn't in the IndieAuth specification, and I'd rather flag it than bury
it. The motivation is that an extension's redirect host is generated per
installation, so a literal declaration is impossible — the client genuinely
cannot know its own callback host ahead of time.

It's deliberately narrow:

• the wildcard stands in for exactly one DNS label;
• scheme, port and path must still match exactly.

So https://*.example.com/ accepts https://abc.example.com/ and rejects
https://example.com/, https://a.b.example.com/,
http://abc.example.com/ and https://abc.example.com/other.

If you'd prefer wildcards gated behind an option, or dropped entirely, the
rest of the change stands on its own — declared-URI matching is useful
regardless.

Behavioural changes

• validateRedirect is now async. Both callers await it, and
  codeValidator becomes async to do so.
• Cross-host authorization requests now make one outbound fetch to
  client_id. Same-host requests are unaffected.

I deliberately did not add caching. getClientInformation already
fetches client_id uncached on every authorization request, so this matches
existing behaviour; and since client_id is attacker-supplied, a naive
per-client_id cache is an unbounded map keyed by untrusted input. Happy to
add a bounded cache if you'd like one.

Testing

• Extends test/unit/redirect.js; the original assertions are unchanged.
  25/25 unit tests pass in endpoint-auth (up from 17).
• New fixtures in helpers/mock-agent/endpoint-auth.js, following the
  existing mockAgent("endpoint-auth") convention.
• Covers: declaration via <link> tag and via Link header; undeclared and
  unrelated hosts; path and scheme mismatch; wildcard match; wildcard
  rejection at the apex, at a deeper subdomain, and on a different domain;
  unfetchable client_id; malformed URLs.
• 38/38 integration tests pass.
• eslint and prettier clean.

Verified end to end against a real client: with this change, a client_id
page declaring https://*.chromiumapp.org/ and
https://*.extensions.allizom.org/ accepts the Chrome and Firefox callbacks
and rejects an undeclared host.

[aciccarello]

Addressing the TODO seems like a good improvement. The wildcard addition definitely seems like something to review. I'd be nervous extending auth code.

@rmdes What the Omnibear browser extension does is it uses a page script to pull the auth from a redirect to omnibear.com rather than redirecting to the extension itself. Worth considering for Plume.

[aciccarello]

Sounds like the Oauth working group strongly discourages wildcards indieweb/indieauth#22 (comment)

[rmdes]

You're right, and it turns out the wildcard isn't needed at all. I've removed it.

Thanks for the link — that's about as authoritative as it gets, and it prompted me to actually check the assumption underneath my patch. I'd believed a browser extension can't predeclare its callback because the browser issues the host. That's wrong in both browsers:

• Chrome uses <extension-id>.chromiumapp.org, and the extension ID is fixed for a published item.
• Firefox uses sha1(<extension id>).extensions.allizom.org. I measured browser.identity.getRedirectURL() on my install and confirmed the subdomain is exactly sha1("plume@rmdes.net"), my pinned browser_specific_settings.gecko.id. It's a pure function of the ID, not a per-install UUID.

So both callbacks are fixed and declarable. I've replaced the wildcards on Plume's client_id page with the two literal URLs, and this PR now matches declared URIs exactly — scheme, host and path, ignoring only a trailing slash. Patterns are matched literally, with a test asserting a declared *. does not expand.

That leaves the PR doing only what the @todo asked: fetch client_id, read <link rel="redirect_uri"> tags and Link headers, match against them. It's ~40 lines smaller than before.

Worth flagging one caveat I can't rule out: Firefox's SHA-1 derivation is observed behaviour, not a documented guarantee — MDN says only "derived from your extension's ID". Stable in practice, but a literal declaration would break if Mozilla ever changed it, where a wildcard wouldn't. I think that's the right trade given the security argument.

On Omnibear — thanks, I didn't know it worked that way. Redirecting to a page on the client_id origin and forwarding the code to the extension makes the redirect same-origin and sidesteps this entirely. I'll look at it for Plume regardless of what happens here; it'd also mean Plume works against servers that haven't implemented cross-host validation.

[paulrobertlloyd]

This looks great, thanks @rmdes. And yes, best that this PR implemented only the @todo, sounds like the wildcard support is not needed and not advisable.