Google and Apple Sign-In in Expo, Verified by FastAPI

Key facts, with sources

• In the JetBrains Python Developers Survey 2024, which collected responses from more than 30,000 Python developers, FastAPI usage jumped from 29% to 38%, overtaking Django (35%) and Flask (34%) as the most-used Python web framework. (JetBrains Python Developers Survey 2024)
• The 2025 Stack Overflow Developer Survey shows FastAPI at 14.8% of respondents doing extensive work with it, edging out Flask at 14.4% and Django at 12.6%. (Stack Overflow Developer Survey 2025)
• FastAPI's official documentation cites independent TechEmpower benchmarks showing FastAPI applications running under Uvicorn as one of the fastest Python frameworks available, ranked only below Starlette and Uvicorn themselves. (FastAPI official documentation)
• FastAPI surpassed Flask in GitHub stars in December 2025, reaching roughly 88,000 stars compared to Flask's 68,400. (DZone)
• Industry analysis of FastAPI's 2025 growth reports about 40% year-over-year growth in job mentions and production adoption at companies including Uber, Netflix, and Microsoft. (byteiota)

The flow: verify once, then use your own tokens

The client runs the provider's sign-in and gets back an ID token — a signed JWT from Google or Apple. It sends that token to a single endpoint on your backend. The backend verifies it, maps it to a user in your database, and issues your own access and refresh tokens. Every request after that carries your JWT, validated by your rotation and reuse-detection logic. The provider participated in exactly one request.

The reason not to skip the exchange: if your API trusts Google's token directly, you inherit Google's expiry, Google's audience rules, and no ability to revoke or rotate on your terms. Minting your own session decouples your app from the identity provider entirely.

Verify the Google ID token in FastAPI

Google publishes its public keys; the google-auth library fetches and caches them and checks the signature, expiry, and audience in one call. Confirm the issuer too, then create or fetch the user and return your own tokens.

from google.oauth2 import id_token
from google.auth.transport import requests as google_requests

GOOGLE_CLIENT_ID = "your-client-id.apps.googleusercontent.com"

@router.post("/auth/google")
def google_sign_in(body: GoogleIn, db: Session = Depends(get_db)):
    try:
        # Verifies signature, expiry, and audience against Google's public keys.
        claims = id_token.verify_oauth2_token(
            body.id_token, google_requests.Request(), GOOGLE_CLIENT_ID
        )
    except ValueError:
        raise HTTPException(401, "invalid Google token")

    if claims["iss"] not in ("accounts.google.com", "https://accounts.google.com"):
        raise HTTPException(401, "wrong issuer")

    user = get_or_create_user(db, email=claims["email"], name=claims.get("name"))

    # From here the app uses YOUR tokens; Google is out of the request path.
    return {
        "access_token": mint_access_token(user.id),
        "refresh_token": issue_refresh_token(db, user.id),
    }

Apple's extra rules

Apple sign-in follows the same verify-then-exchange shape but has two quirks that bite teams. First, Apple only sends the user's name on the very first authorization — if you do not capture it then, you never get it again, so persist it on first sign-in. Second, many users choose Apple's private relay email (a masked address); treat that as the stable identifier and do not assume you can email it through arbitrary providers. Verify Apple's identity token against Apple's public keys the same way, checking the issuer is https://appleid.apple.com and the audience is your app's bundle or service ID.

One user, multiple sign-in methods

Match federated logins to existing accounts by verified email so a user who signed up with a password and later taps Sign in with Google lands on the same account, not a duplicate. Store which providers are linked. The exchange endpoint stays the entry point for every provider — each one verifies its own token, then converges on the same get_or_create_user and the same token issuance.

When to hire senior help

Bring in senior help when your API needs to handle real concurrency, when you are designing service boundaries and auth for the first time, or when an existing FastAPI codebase mixes sync and async code and latency is degrading. An experienced engineer can usually diagnose event-loop blocking and connection-pool misconfiguration in days, which is far cheaper than re-architecting after launch. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships Python — FastAPI Development projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Calling blocking libraries (classic SQLAlchemy sessions, requests, heavy file I/O) inside async def endpoints, which stalls the event loop and erases FastAPI's concurrency advantage
• ✕Deploying a single Uvicorn process with no process manager or worker scaling, leaving most CPU cores idle under production load
• ✕Treating the auto-generated OpenAPI docs as a versioning strategy, then breaking mobile and partner clients when response schemas change
• ✕Running large payloads through deeply nested Pydantic models on every request and response, adding serialization latency that shows up only at scale

Frequently asked questions

Sources

• JetBrains Python Developers Survey 2024
• Stack Overflow Developer Survey 2025
• FastAPI official documentation
• DZone
• byteiota