Complete NextAuth OAuth implementation and documentation

[marcodejongh]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
boardsesh	Error		Jan 5, 2026 0:24am

[claude]

Claude Review

✅ Ready to merge - Minor issues noted below, but nothing blocking.

Issues

1. Missing tests for new API routes - Tests exist for rate-limiter.ts but no tests for:

   • /api/auth/register - registration flow, edge cases (existing user, OAuth user adding password)
   • /api/auth/verify-email - token validation, expiration handling
   • /api/auth/resend-verification - rate limiting, timing attack prevention
   • /api/auth/providers-config - environment variable detection

2. Email service lacks error handling tests - packages/web/app/lib/email/email-service.ts has no tests for:

   • SMTP connection failures
   • Invalid email format handling
   • Missing environment variable scenarios

3. Potential user enumeration via register endpoint - packages/web/app/api/auth/register/route.ts:67-71 returns "An account with this email already exists" which confirms account existence. Consider using a generic message like the resend-verification endpoint does.

4. User ID exposure in registration response - packages/web/app/api/auth/register/route.ts:82,138 returns userId in the response. This is generally unnecessary for the client and could be removed.

Documentation

New docs/oauth-setup.md is comprehensive and well-structured.

[claude]

Claude Review

✅ Ready to merge - Minor issues noted below, but nothing blocking.

Issues

1. register/route.ts:138 - Response includes userId which could be unnecessary information disclosure for new accounts.

2. rate-limiter.ts:4-18 - The in-memory rate limiter is acknowledged to be ineffective in serverless environments, which is well-documented. For a production system with strict requirements, Redis-based limiting should be prioritized. The current implementation provides minimal protection.

3. social-login-buttons.tsx:105,118,139 - Uses inline style properties instead of CSS classes/design tokens, contrary to the CLAUDE.md guideline: "Try to avoid use of the style property".

4. verify-email/route.ts - No rate limiting on the verification endpoint. An attacker could brute-force valid tokens (though tokens are UUIDs, making this impractical).

5. resend-verification/route.ts:29 - Generic success message is good for security, but the 2.5s delay for timing attack prevention significantly impacts UX for legitimate users.

Test Coverage

Rate limiter tests are comprehensive with good coverage of edge cases (window expiry, different identifiers, IP extraction). However, no tests exist for:

• Registration endpoint
• Verification endpoints
• Email service

Documentation

New docs/oauth-setup.md is comprehensive and well-structured. No existing documentation files need updates from these changes.

[claude]

Claude Review

✅ Ready to merge - Minor issues noted below, but nothing blocking.

Issues

1. In-memory rate limiter ineffective in serverless (packages/web/app/lib/auth/rate-limiter.ts:20-21)

   • The documentation acknowledges this but it still results in effectively no rate limiting in production on Vercel. Consider at minimum using Vercel KV or adding a header comment in routes that this is best-effort only.

2. Race condition in registration (packages/web/app/api/auth/register/route.ts:52-84)

   • Check for existing user and insert are not atomic. Two concurrent registrations with the same email could both pass the check. The database unique constraint will catch this but will throw an unhandled error. Wrap in try/catch or use upsert pattern.

3. Missing test coverage for API routes

   • Tests only cover the rate-limiter utility. No tests for /api/auth/register, /api/auth/verify-email, or /api/auth/resend-verification routes. Consider adding integration tests for critical auth flows (registration, verification, error cases).

4. Token not cryptographically random (packages/web/app/api/auth/register/route.ts:111, packages/web/app/api/auth/resend-verification/route.ts:87)

   • Uses crypto.randomUUID() which is sufficient for verification tokens but using crypto.randomBytes(32).toString("hex") would provide more entropy for security-sensitive tokens.

5. Inconsistent timing protection (packages/web/app/api/auth/register/route.ts)

   • The resend-verification endpoint has timing attack protection via consistentDelay(), but the register endpoint lacks this, allowing email enumeration via response time differences between "email exists" and "new user" paths.

[claude]

Claude Review

✅ Ready to merge - Minor issues noted below, but nothing blocking.

Issues

1. Race condition in register route (packages/web/app/api/auth/register/route.ts:111-120): If the user insert succeeds but credentials insert fails, the user is left in an inconsistent state with no password. Consider wrapping user + credentials + profile inserts in a transaction.

2. Test module reset doesn't clear memory store (packages/web/app/lib/auth/__tests__/rate-limiter.test.ts:6-8): vi.resetModules() doesn't actually clear the memoryStore Map since it's instantiated at module load. Tests use unique timestamp-based identifiers to work around this, but it would be cleaner to export a clearStore() function for testing.

3. Missing test coverage for email service: No tests for packages/web/app/lib/email/email-service.ts. Critical functionality like email sending and HTML escaping should have unit tests.

4. Missing test coverage for auth routes: No tests for verify-email, resend-verification, or register API routes. Edge cases like expired tokens, race conditions, and error handling would benefit from integration tests.

5. Rate limiter IP fallback security (packages/web/app/lib/auth/rate-limiter.ts:81): When no IP is found, all requests share a single unknown bucket. A malicious actor without proxy headers could still be rate limited alongside legitimate users, but this fallback could be more aggressive (e.g., lower limit for unknown IPs).

Documentation

New docs/oauth-setup.md is comprehensive and well-structured.

[claude]

Claude Review

✅ Ready to merge - Minor issues noted below, but nothing blocking.

Issues

1. verify-email/route.ts:92-95 - Non-atomic verify + delete: The user update and token deletion should be in a transaction to prevent inconsistent state if one fails.

2. resend-verification/route.ts:81-97 - Non-atomic delete + insert: Deleting existing tokens and creating a new one should be wrapped in a transaction to avoid race conditions.

3. register/route.ts:74-84 - Adding password to OAuth user doesn't send verification email or require verification, yet new users require it. This creates inconsistent UX for account linking.

4. email-service.ts:60 - baseUrl parameter is not validated/sanitized. While unlikely to be exploited since it comes from env vars, a malformed NEXTAUTH_URL could create issues.

5. social-login-buttons.tsx:85-90 - Loading state shows 3 skeleton buttons regardless of which providers are actually configured, causing layout shift when fewer providers exist.

Test Coverage Note

The rate-limiter tests are good but there are no tests for:

• Email service (sendVerificationEmail)
• API routes (register, verify-email, resend-verification)
• Auth callbacks and error handling flows

This is acceptable for initial implementation but should be added for production readiness.

[claude]

Claude Review

✅ Ready to merge - Minor issues noted below, but nothing blocking.

Issues

1. Registration reveals user enumeration - packages/web/app/api/auth/register/route.ts:68-70: When an account exists with credentials, returns 409 with specific message. Consider using timing-safe responses to prevent enumeration attacks (similar to the resend-verification endpoint's approach).

2. Missing test coverage for edge cases:

   • No tests for email-service.ts (SMTP failure handling, HTML escaping)
   • No tests for register/route.ts, verify-email/route.ts, or resend-verification/route.ts
   • Rate limiter tests don't cover cleanup interval behavior

3. Token uses UUID instead of cryptographically secure random - packages/web/app/api/auth/register/route.ts:102 and resend-verification/route.ts:82: crypto.randomUUID() is used for verification tokens. While acceptable, crypto.randomBytes(32).toString('hex') would provide higher entropy for security-sensitive tokens.

4. Space component prop issue - packages/web/app/components/auth/social-login-buttons.tsx:101: block prop on Space component may not work as expected in all AntD versions. Consider using CSS width: 100% instead.