go-pkgz / auth / 25606477506

85%

push

github

fix(verify): one-shot consumption of email confirmation tokens

The email confirmation JWT issued by VerifyHandler.sendConfirmation was
only protected by its 30-minute expiry: any party who could read the
confirmation link (forwarded email, mail-gateway logs, mailbox archive)
could redeem it independently within the window, creating a separate
authenticated session for the same address.

Add a VerifConfirmationStore interface (MarkUsed key, ttl -> bool) and a
default in-memory implementation (sync.Mutex-protected map keyed by
SHA-256 of the raw token). When VerifyHandler.ConfirmationStore is
non-nil, LoginHandler records the token as consumed on first redemption
and rejects replays with 403 "confirmation token already consumed".

The store key is the SHA-256 of the raw token rather than a jti claim,
so existing token fixtures (which carry no jti) are still de-dup'd
correctly without changing the wire format.

Wired through Service.AddVerifProvider in both auth.go and v2/auth.go.
The store is selected once via sync.Once, with this precedence:

  1. Opts.VerifConfirmationStore if non-nil (caller-supplied; required
     for multi-instance deployments — Redis or any shared KV).
  2. provider.NewInMemoryVerifStore() default — fine for single
     instance, broken for LB-fronted multi-instance deployments where
     instance A's "used" set is unknown to instance B. Documented in
     README under "Confirmation token replay protection".

Tests:
* TestInMemoryVerifStore — store-level coverage (replay, expiry, key
  independence).
* TestVerifyHandler_LoginAcceptConfirm_RejectsReplay — integration:
  same token redeemed twice -> 200 then 403.
* TestService_AddVerifProvider_UsesCustomConfirmationStore — Opts
  injection works.
* TestService_AddVerifProvider_DefaultsToInMemory — default install
  + sync.Once reuse on subsequent AddVerifProvider calls.

64 of 68 new or added lines in 2 files covered. (94.12%)

2953 of 3466 relevant lines covered (85.2%)

8.06 hits per line