fix(auth): make token optional and relax linked account type validation

[vdimarco]

Summary

• Make token field optional in PrivyAuthRequest schema (not currently used for validation)
• Add type normalization for Privy account types (sms→phone, github_oauth→github, etc.)
• Expand valid linked account types to include twitter, passkey, smart_wallet, etc.
• Log unknown account types as warnings instead of rejecting them (breaking auth)

Context

The strict token requirement and account type validation were causing login failures:

1. Frontend sometimes couldn't retrieve Privy token but the backend rejected empty tokens
2. Privy sends account types like sms but backend only accepted phone

Security Notes

• Token field is not used for actual authentication validation (user is authenticated via Privy ID)
• Unknown account types are logged but passed through - this is intentional to prevent auth breakage from new Privy account types

Test plan

• Login with email
• Login with Google OAuth
• Login with GitHub OAuth
• Login with SMS (if available)

🤖 Generated with Claude Code

Greptile Overview

Greptile Summary

This PR improves authentication robustness by making the token field optional in PrivyAuthRequest and relaxing linked account type validation. The changes prevent login failures when the frontend cannot retrieve a Privy token or when Privy sends account types in different formats.

Key Changes:

• Made token field optional with default None (not currently used for authentication)
• Added type normalization mapping (sms→phone, github_oauth→github, etc.)
• Expanded valid account types to include twitter, passkey, smart_wallet, cross_app, wallet
• Changed strict validation to log warnings for unknown types instead of rejecting them

Impact:
The changes improve authentication reliability by handling Privy's various account type formats gracefully. Since the token field is not used for actual authentication validation (user is authenticated via Privy ID), making it optional poses no security risk.

Confidence Score: 4/5

• This PR is safe to merge with low risk - changes improve authentication reliability without compromising security
• Score reflects well-justified changes that fix real authentication issues. The token field is confirmed unused for validation (only privy_user_id matters), so making it optional is safe. The relaxed account type validation is appropriate given Privy's evolving account types. One point deducted because the unused token field could be removed entirely in a future cleanup.
• No files require special attention

Important Files Changed

Filename	Overview
src/schemas/auth.py	Makes token optional and relaxes account type validation with normalization, improving login compatibility with Privy's various account types

Sequence Diagram

sequenceDiagram
    participant Frontend
    participant FastAPI as FastAPI Auth Route
    participant Schema as PrivyAuthRequest Schema
    participant Validator as Account Type Validator
    participant Auth as Auth Handler
    participant DB as Database

    Frontend->>FastAPI: POST /auth (Privy user data)
    Note over Frontend,FastAPI: token field is optional now
    FastAPI->>Schema: Validate PrivyAuthRequest
    
    alt Token provided (optional)
        Schema->>Schema: Accept token (not validated)
    else Token missing
        Schema->>Schema: Accept None (no error)
    end
    
    Schema->>Validator: Validate linked account types
    
    alt Account type needs normalization
        Validator->>Validator: Normalize type<br/>(sms→phone, github_oauth→github)
    end
    
    alt Known account type
        Validator->>Validator: Return normalized type
    else Unknown account type
        Validator->>Validator: Log warning, pass through
    end
    
    Schema->>FastAPI: Validation successful
    FastAPI->>Auth: Process authentication
    Auth->>DB: Lookup/create user by privy_user_id
    DB->>Auth: User data
    Auth->>FastAPI: Authentication result
    FastAPI->>Frontend: PrivyAuthResponse with API key

Loading

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[supabase]

This pull request has been ignored for the connected project ynleroehyrmaafkgjgmr because there are no changes detected in supabase/supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

[coderabbitai]

Warning

Rate limit exceeded

@vdimarco has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 6 minutes and 56 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/auth-token-and-account-types

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

❌ CI pipeline failed. Auto-merge is disabled until all checks pass.