I’m trying to add Google and Apple sign in to a web app. What setup do I actually need?

To add Google Sign-In and Apple Sign In to a web app, you usually need three things:

1. A frontend button/flow
2. A backend endpoint to verify the token/code
3. Provider app registrations/configuration

Here’s the practical setup.

---

1) Google Sign-In setup

In Google Cloud Console

Create a project and configure OAuth 2.0 Client IDs.

You’ll typically need:

• OAuth consent screen
  • App name
  • Support email
  • Authorized domains
  • Privacy policy / terms URLs if going live
• OAuth client ID for Web application
  • Authorized JavaScript origins
    • e.g. http://localhost:3000
    • https://yourdomain.com
  • Authorized redirect URIs
    • only if using redirect/code flow
    • e.g. https://yourdomain.com/auth/google/callback

On your app

You can use either:

• Google Identity Services button + ID token
  • easiest for simple sign-in
  • frontend receives an ID token
  • backend verifies it
• OAuth authorization code flow
  • better if you need access to Google APIs later
  • frontend gets a code, backend exchanges it

Backend verification

Your backend should verify:

• token signature
• issuer
• audience matches your client ID
• expiry

Then create your own session/JWT for your app.

---

2) Apple Sign In setup

Apple is a bit more involved.

In Apple Developer account

You need:

• Apple Developer Program membership
• Create an App ID / Service ID
  • for web apps, usually a Service ID
• Enable “Sign in with Apple”
• Configure:
  • Return URL(s) / redirect URI(s)
  • Domains and subdomains
• Create a Sign in with Apple key
  • used to generate client secret JWTs
  • you’ll need:
    • Team ID
    • Key ID
    • downloaded private key (.p8)

On your app

Apple Sign In on web generally uses the OAuth flow:

• user signs in
• Apple returns an authorization code / identity token
• backend exchanges/verifies
• backend creates your app session

Important Apple specifics

• Apple often only provides the user’s name/email on first authorization
• Use a real HTTPS domain in production
• Your backend may need to generate a client secret JWT to talk to Apple’s token endpoint

---

3) What your backend should do for both

No matter which provider you use, your backend should:

• receive the provider response
• verify it with the provider’s public keys or token endpoint
• map provider user info to your internal user
• create/update your user record
• issue your own app session:
  • server session cookie, or
  • your own JWT

Do not trust frontend-provided user info alone.

---

4) Common minimal setup for a web app

If you want the simplest production-ready version:

Google

• Google OAuth consent screen
• Web OAuth client ID
• Frontend sign-in button
• Backend token verification

Apple

• Apple Developer Program
• Service ID
• Sign in with Apple enabled
• Return URL(s)
• Private key (.p8)
• Backend code to generate client secret and verify response

App infrastructure

• HTTPS in production
• Backend endpoint for callback/token verification
• Secure session storage
• User database with provider IDs like:
  • google_sub
  • apple_sub

---

5) Recommended architecture

A common pattern:

• Frontend
  • renders “Sign in with Google” and “Sign in with Apple”
• Backend
  • handles OAuth callback or token verification
  • creates app session
• Database
  • stores linked provider account IDs and your internal user ID

---

6) Things people often forget

• Apple requires the first-party developer setup and is stricter than Google
• You need matching redirect URIs exactly
• Use HTTPS in production
• Save provider-specific unique IDs, not just email
• Decide whether you want:
  • login only
  • or login + API access later
• Test in a real browser with cookies/storage considerations

---

7) If you want the absolute minimum

For Google only

• Google Cloud project
• OAuth client ID for web
• frontend button
• backend token verification

For Apple only

• Apple Developer account
• Service ID
• Sign in with Apple key
• redirect URI
• backend token exchange/verification

---

If you want, I can give you:

1. a checklist for Google,
2. a checklist for Apple, or
3. a sample architecture for React + Node/Express.