authv2 jwts

[Makisuo]

No description provided.

[vercel]

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

Project	Deployment	Review	Updated (UTC)
hazel-docs	Error		Jan 24, 2026 0:18am

[claude]

Claude finished @Makisuo's task —— View job

---

Code Review: AuthV2 JWT Implementation

I've completed my review of the JWT authentication implementation. This is a well-architected change that properly migrates from cookie-based auth to JWT tokens for both web and desktop platforms.

Todo List:

• Analyze new authentication architecture and JWT handling
• Review token storage implementation for security
• Check callback handling and error management
• Examine backend auth route changes
• Review web auth atoms and state management
• Check for potential security vulnerabilities
• Assess performance implications
• Provide comprehensive feedback

---

✅ Architecture & Design

Strong Points:

• Excellent separation between web and desktop auth with platform-aware logic
• Proper Effect-TS patterns throughout with service definitions
• Clean atom-based state management using Effect Atom
• Comprehensive error handling with typed errors and retry logic
• Good abstraction - authenticatedFetch seamlessly handles both platforms

Architecture Decision:

• Moving from cookie-based to JWT-based auth is sound for cross-platform support
• The fallback mechanism (web → localStorage, desktop → Tauri secure storage) is appropriate

⚠️ Security Concerns

Critical Issues:

1. localStorage for sensitive tokens (apps/web/src/lib/services/web/token-storage.ts):

   • Storing JWTs in localStorage exposes them to XSS attacks
   • Recommendation: Consider httpOnly cookies for web or implement additional XSS mitigations
   • Document this security trade-off if localStorage is intentional

2. Token exposure in console logs (apps/web/src/atoms/web-auth.ts:206):

   yield* Effect.log("[web-auth] Tokens refreshed successfully")

   • Ensure logging doesn't accidentally expose token values in production

Good Security Practices:

• Proper token refresh with 5-minute buffer
• Fatal error detection for revoked tokens
• Session expiry event dispatching for cleanup
• State validation in OAuth callback

🔒 Token Storage Analysis

Web Implementation (token-storage.ts):

• ✅ Good: Proper error handling with typed errors
• ✅ Good: Null checks and storage availability validation
• ✅ Good: Atomic operations for storing/clearing all tokens
• ⚠️ Risk: localStorage vulnerable to XSS (see security section above)

Token Refresh Logic (web-auth.ts):

• ✅ Excellent: Prevents concurrent refreshes with deferred pattern
• ✅ Good: Retry logic with exponential backoff for transient errors
• ✅ Good: Distinguishes between fatal and transient errors
• ✅ Good: Proper cleanup with finalizers

🔄 Callback Handling

OAuth Flow (callback.tsx + web-callback-atoms.ts):

• ✅ Excellent: Type-safe state parsing with Schema validation
• ✅ Good: Proper error categorization and retry logic
• ✅ Good: User-friendly error messages and retry UI
• ✅ Good: Proper cleanup and navigation on success

🏗️ Backend Changes

Auth Routes (auth.http.ts):

• ✅ Good: Simplified routes focusing on token exchange
• ✅ Good: Proper JWT expiry calculation using getJwtExpiry
• ✅ Good: Maintains user creation/sync with WorkOS
• ✅ Good: Input validation for state parameters

New User RPC (users.ts):

• ✅ Good: New resetAvatar endpoint properly syncs with WorkOS
• ✅ Good: Follows existing patterns with policies and transactions

⚡ Performance Considerations

Positive:

• Efficient token refresh scheduling prevents unnecessary API calls
• Concurrent refresh prevention reduces load
• Atomic localStorage operations minimize blocking

Potential Optimizations:

• Consider implementing token refresh based on actual expiry vs fixed buffer
• The refresh retry logic is well-implemented but could benefit from circuit breaker for repeated failures

🧪 Test Coverage

Good Coverage:

• auth-fetch.test.ts covers web authentication flows well
• Tests platform detection and error scenarios

Missing Coverage:

• No tests found for new web-auth.ts atoms
• No tests for web-callback-atoms.ts callback logic
• No tests for WebTokenStorage service

Recommendation: Add unit tests for the new web auth atoms and token storage service.

🔧 Code Quality

Excellent:

• Consistent Effect-TS patterns with proper service definitions
• Clean separation of concerns
• Comprehensive error handling
• Good TypeScript usage with proper types
• Clear documentation and comments

Minor Issues:

• Some magic numbers could be constants (5 minute refresh buffer, retry counts)
• Consider extracting token validation logic into separate utility

📊 Overall Assessment

This is a high-quality implementation that properly migrates to JWT authentication while maintaining security and usability. The architecture is solid and follows established patterns in the codebase.

Priority Recommendations:

1. High: Review localStorage security implications and document the XSS risk trade-off
2. Medium: Add test coverage for new web auth atoms and callback logic
3. Low: Extract magic numbers to named constants

The implementation demonstrates excellent understanding of Effect-TS patterns and provides a robust foundation for JWT authentication across platforms.

---

[railway-app]

🚅 Deployed to the hazel-pr-254 environment in hazel

Service	Status	Web	Updated (UTC)
electric-proxy	✅ Success (View Logs)		Jan 24, 2026 at 12:19 am
api	✅ Success (View Logs)		Jan 24, 2026 at 12:19 am
docs	✅ Success (View Logs)		Jan 24, 2026 at 12:19 am
cluster	✅ Success (View Logs)		Jan 24, 2026 at 12:19 am
otel-collector	✅ Success (View Logs)	Web	Jan 24, 2026 at 12:14 am

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	29.42%	701 / 2382
🔵	Statements	29.78%	735 / 2468
🔵	Functions	15.38%	110 / 715
🔵	Branches	14.87%	134 / 901

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
apps/web/src/atoms/web-auth.ts	10.65%	0%	0%	11.17%	93, 115-118, 125-131, 140-277, 291-315, 325-326, 340-381, 393-428, 440-449, 459-469, 478-527
apps/web/src/lib/auth-fetch.ts	38.33%	35%	33.33%	38.33%	27-34, 47-67, 77, 86-89, 131-165
apps/web/src/lib/services/web/token-storage.ts	8.06%	0%	0%	8.19%	19-227
packages/domain/src/rpc/users.ts	100%	100%	100%	100%

Generated in workflow #1361 for commit 98d6956 by the Vitest Coverage Report Action

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	hazel-app	98d6956	Commit Preview URL Branch Preview URL	Jan 24 2026, 12:19 AM

[claude]

Claude finished @Makisuo's task —— View job

---

Code Review: AuthV2 JWT Implementation

I've completed my review of the JWT authentication implementation. This is a well-architected change that properly migrates from cookie-based auth to JWT tokens for both web and desktop platforms.

Todo List:

• Analyze new authentication architecture and JWT handling
• Review token storage implementation for security
• Check callback handling and error management
• Examine backend auth route changes
• Review web auth atoms and state management
• Check for potential security vulnerabilities
• Assess performance implications
• Provide comprehensive feedback

---

✅ Architecture & Design

Strong Points:

• Excellent separation between web and desktop auth with platform-aware logic
• Proper Effect-TS patterns throughout with service definitions
• Clean atom-based state management using Effect Atom
• Comprehensive error handling with typed errors and retry logic
• Good abstraction - authenticatedFetch seamlessly handles both platforms

Architecture Decision:

• Moving from cookie-based to JWT-based auth is sound for cross-platform support
• The fallback mechanism (web → localStorage, desktop → Tauri secure storage) is appropriate

⚠️ Security Concerns

Critical Issues:

1. localStorage for sensitive tokens (apps/web/src/lib/services/web/token-storage.ts):

   • Storing JWTs in localStorage exposes them to XSS attacks
   • Recommendation: Consider httpOnly cookies for web or implement additional XSS mitigations
   • Document this security trade-off if localStorage is intentional

2. Token exposure in console logs (apps/web/src/atoms/web-auth.ts:206):

   yield* Effect.log("[web-auth] Tokens refreshed successfully")

   • Ensure logging doesn't accidentally expose token values in production

Good Security Practices:

• Proper token refresh with 5-minute buffer
• Fatal error detection for revoked tokens
• Session expiry event dispatching for cleanup
• State validation in OAuth callback

🔒 Token Storage Analysis

Web Implementation (token-storage.ts):

• ✅ Good: Proper error handling with typed errors
• ✅ Good: Null checks and storage availability validation
• ✅ Good: Atomic operations for storing/clearing all tokens
• ⚠️ Risk: localStorage vulnerable to XSS (see security section above)

Token Refresh Logic (web-auth.ts):

• ✅ Excellent: Prevents concurrent refreshes with deferred pattern
• ✅ Good: Retry logic with exponential backoff for transient errors
• ✅ Good: Distinguishes between fatal and transient errors
• ✅ Good: Proper cleanup with finalizers

🔄 Callback Handling

OAuth Flow (callback.tsx + web-callback-atoms.ts):

• ✅ Excellent: Type-safe state parsing with Schema validation
• ✅ Good: Proper error categorization and retry logic
• ✅ Good: User-friendly error messages and retry UI
• ✅ Good: Proper cleanup and navigation on success

🏗️ Backend Changes

Auth Routes (auth.http.ts):

• ✅ Good: Simplified routes focusing on token exchange
• ✅ Good: Proper JWT expiry calculation using getJwtExpiry
• ✅ Good: Maintains user creation/sync with WorkOS
• ✅ Good: Input validation for state parameters

New User RPC (users.ts):

• ✅ Good: New resetAvatar endpoint properly syncs with WorkOS
• ✅ Good: Follows existing patterns with policies and transactions

⚡ Performance Considerations

Positive:

• Efficient token refresh scheduling prevents unnecessary API calls
• Concurrent refresh prevention reduces load
• Atomic localStorage operations minimize blocking

Potential Optimizations:

• Consider implementing token refresh based on actual expiry vs fixed buffer
• The refresh retry logic is well-implemented but could benefit from circuit breaker for repeated failures

🧪 Test Coverage

Good Coverage:

• auth-fetch.test.ts covers web authentication flows well
• Tests platform detection and error scenarios

Missing Coverage:

• No tests found for new web-auth.ts atoms
• No tests for web-callback-atoms.ts callback logic
• No tests for WebTokenStorage service

Recommendation: Add unit tests for the new web auth atoms and token storage service.

🔧 Code Quality

Excellent:

• Consistent Effect-TS patterns with proper service definitions
• Clean separation of concerns
• Comprehensive error handling
• Good TypeScript usage with proper types
• Clear documentation and comments

Minor Issues:

• Some magic numbers could be constants (5 minute refresh buffer, retry counts)
• Consider extracting token validation logic into separate utility

📊 Overall Assessment

This is a high-quality implementation that properly migrates to JWT authentication while maintaining security and usability. The architecture is solid and follows established patterns in the codebase.

Priority Recommendations:

1. High: Review localStorage security implications and document the XSS risk trade-off
2. Medium: Add test coverage for new web auth atoms and callback logic
3. Low: Extract magic numbers to named constants

The implementation demonstrates excellent understanding of Effect-TS patterns and provides a robust foundation for JWT authentication across platforms.

---