feat: migrate to OAuth PKCE flow

[jdjkelly]

Summary

• Replaces the legacy Link-based flow with OAuth 2.0 PKCE
• Updates to @flexpa/node-sdk 1.0.0

Changes

• Add OAuth PKCE authorization utilities (src/lib/oauth.ts)
• Add /callback route for handling OAuth redirects
• Update session management for access tokens
• Remove deprecated /api/exchange route
• Remove deprecated launch-link component

Related PRs

• SDK OAuth PKCE: https://github.com/flexpa/flexpa/pull/8788
• SDK Docs: https://github.com/flexpa/flexpa/pull/8789
• Quickstart Docs: https://github.com/flexpa/flexpa/pull/8792

🤖 Generated with Claude Code

---

Important

Migrates authentication to OAuth 2.0 PKCE, updating session management and removing deprecated components.

• Authentication Flow:
  • Replaces legacy Link-based flow with OAuth 2.0 PKCE.
  • Adds startOAuthFlow() in oauth.ts to initiate PKCE flow.
  • Adds /callback route in callback/route.ts to handle OAuth redirects and token exchange.
• Session Management:
  • Updates session handling in session.ts to store and retrieve code verifier and access tokens.
  • Adds setCodeVerifier(), getCodeVerifier(), and deleteCodeVerifier() in session.ts.
• Component and Route Removal:
  • Removes launch-link component.
  • Deletes deprecated /api/exchange route.
• Dependencies:
  • Updates @flexpa/node-sdk to version 1.0.0 in package.json.
• Environment Variables:
  • Adds NEXT_PUBLIC_REDIRECT_URI to .env.example.

^{This description was created by for 7420c83. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 7420c83 in 2 minutes and 16 seconds. Click for details.

• Reviewed 263 lines of code in 9 files
• Skipped 2 files when reviewing.
• Skipped posting 8 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. .env.example:4

• Draft comment:
  Ensure NEXT_PUBLIC_REDIRECT_URI is updated for production if needed.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is asking the PR author to ensure that a specific environment variable is updated for production. It is not making a specific code suggestion or pointing out a potential issue with the code itself. It falls under the category of asking the author to ensure something is done, which is against the rules.

2. package.json:11

• Draft comment:
  Verify that the breaking changes in @flexpa/node-sdk v1.0.0 align with your implementation.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is asking the PR author to verify alignment with breaking changes in a dependency, which is not allowed according to the rules. It does not provide a specific suggestion or point out a specific issue in the code.

3. src/app/api/sync/route.ts:12

• Draft comment:
  Renaming the request parameter to _request clarifies it is unused.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

4. src/app/callback/route.ts:32

• Draft comment:
  Using non-null assertions (!) for env variables may cause runtime errors if they're missing.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment is technically accurate but falls into a gray area. The code already has error handling via try-catch, so runtime errors would be caught. The comment doesn't suggest a specific fix - should they add validation? Use optional chaining? Add a default value? It's more of an informative observation than an actionable code change request. According to the rules, comments should not be purely informative and must clearly require a code change. This feels like a "be careful" comment rather than "you must fix this" comment. The existing error handling already addresses the concern. The environment variables might genuinely be missing in some deployment scenarios, and the try-catch might not provide a clear error message about which specific env var is missing. The comment could be prompting the author to add explicit validation that would improve debugging. While explicit validation could improve error messages, the comment doesn't suggest this specific improvement. It's a general warning without a clear action item. The existing try-catch already prevents the application from crashing, which addresses the "runtime errors" concern mentioned in the comment. This comment is informative but not actionable. It doesn't clearly specify what code change is needed, and the existing error handling already prevents runtime crashes. Without a specific suggestion for improvement, this falls into the category of comments that should be removed.

5. src/app/callback/route.ts:45

• Draft comment:
  Consider using structured logging or conditionally logging errors for production.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

6. src/app/page.tsx:8

• Draft comment:
  Wrap the startOAuthFlow call in try/catch to handle potential errors.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment is suggesting error handling, which could be considered a code quality improvement. However, I need to consider: 1) Is this obvious? 2) Is this speculative ("if X happens, then Y")? 3) Is there strong evidence this is needed? The comment doesn't know if startOAuthFlow can actually throw errors - it's making an assumption. Without seeing the implementation of startOAuthFlow, we can't definitively say error handling is needed here. The comment is somewhat speculative - it assumes errors are possible without evidence. Additionally, this is a fairly obvious suggestion that any developer would consider if errors were actually occurring. The rules state "Do NOT make speculative comments" and require "STRONG EVIDENCE that the comment is correct." Error handling is generally a good practice for async operations, and OAuth flows can fail for various reasons (network issues, invalid configuration, etc.). The comment might be providing valuable defensive programming advice that prevents runtime errors from breaking the user experience. While error handling is good practice, the comment is speculative without seeing the actual implementation of startOAuthFlow. We don't know if it already handles errors internally, returns a safe default, or if errors are expected to bubble up. The rules explicitly state to avoid speculative comments and require strong evidence. This is a generic "best practice" suggestion without concrete evidence of a problem. This comment should be deleted. It's a speculative suggestion about potential errors without strong evidence that error handling is needed here. We cannot see the implementation of startOAuthFlow to know if errors are properly handled elsewhere or if they would even occur.

7. src/lib/oauth.ts:16

• Draft comment:
  Ensure crypto.randomUUID is supported in your target Node environment or provide a fallback.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is suggesting to ensure compatibility with the target Node environment, which falls under asking the PR author to double-check things. This violates the rules.

8. src/lib/session.ts:70

• Draft comment:
  Consider setting the 'secure' flag to true for cookies in production.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment is about a line that was added in the diff (line 72, secure: false). However, this is a "consider" comment that doesn't clearly indicate a required code change. The author explicitly set secure: false, which suggests this was intentional. The comment is asking them to "consider" changing it for production, which is speculative and not definitive. Additionally, the existing code in the file already has the same pattern (secure: false on line 43), so if this were truly an issue, it would apply to existing code too. The rules state: "Do NOT comment unless there is clearly a code change required" and "Do NOT make speculative comments". This comment uses "Consider" which is not definitive, and doesn't provide strong evidence that this is definitely wrong. The secure flag being false could be a legitimate security concern for production environments, especially for sensitive cookies like code verifiers used in OAuth flows. The author may have intentionally set it to false for local development but forgotten to make it environment-dependent. While the secure flag is important for security, the comment uses "Consider" which makes it speculative rather than definitive. The author explicitly set secure: false, and the same pattern exists in the unchanged code (line 43), suggesting this is an intentional choice. Without clear evidence that this is definitely wrong (like knowing the deployment environment), this is a "nice to have" suggestion rather than a clear code change requirement. This comment should be deleted. It's a speculative "consider" suggestion rather than a clear code change requirement. The author explicitly set secure: false, and the same pattern exists in unchanged code, suggesting this is intentional. The rules state not to make speculative comments or comments that aren't clearly required changes.

Workflow ID: wflow_F60JwO72SsJPWyCk

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}