Repository navigation
feat(core): forward the pre-auth credential on magic link verify and serve the confirm route - #219
Merged
Merged
Conversation
…serve the confirm route
Verify now sends the opening browser's pre-auth session to the auth API when
it has one, read from the signed pre-auth cookie in cookie transport or the
client's Authorization header in bearer transport. A missing or unverifiable
one sends nothing and never becomes a 401. Express, Fastify and Next.js all go
through verifyMagicLinkHandler, which takes the new optional authorization.
The bundled fallback manifest is resynced from the auth API and now lists
POST /magic-link/verify/{token}/confirm, which the manifest catch-alls serve.
The 409 confirmation_required body, requestedFrom included, passes through
unchanged.
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
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.
Summary
Supports the magic link confirmation step added in seamless-auth-api 0.19.0.
GET /magic-link/verify/:tokenforwards the opening browser's pre-auth credential when it has one: the ephemeral token from the signed pre-auth cookie (cookie transport, verified withverifyCookieJwt) or the client'sAuthorizationheader (bearer transport). Missing, stale or forged credentials send noAuthorizationand never yield a 401. Client IP, user agent and the service token are forwarded exactly as before.verifyMagicLinkHandlertakes an optionalauthorization; new core exportmagicLinkVerifyAuthorizationbuilds it. Express, Fastify and Next.js all use the core handler now (Express had its ownauthFetch, Fastify and Next.js usedproxyRequest).ensureCookiesis unchanged: verify stays ungated, the handler reads the cookie itself. No new manifest credential kind.409 confirmation_requiredpasses through verbatim,requestedFromincluded (asserted in core and in both parity suites).POST /magic-link/verify/{token}/confirmis served by the manifest catch-alls. Bundled manifest regenerated withnode scripts/sync-adapter-manifest.mjsfrom the API branch's adapter-manifest.json. Origin guard covers it (cross-site POST gets 403, tested in Express and both parity suites).minorfor core, express, fastify, nextjs.Merge after the API change is released.
Checks (local, Node v24.18.0, pnpm 10.33.0)
Release order
Part of the v0.19 security release (fells-code/seamless-auth-api#385). Merge this before fells-code/seamless-auth-api#449: that PR's conformance run builds this repo from main, and its Next.js same-browser magic link case needs the pre-auth credential forwarded on verify. Compatible with the current API, which ignores an Authorization header on verify.