I’m building a mobile app with Apple sign-in and email/password login. How should I design the auth flow?

A good mobile auth design is usually:

1. Choose a single backend identity system
2. Treat Apple and email/password as two ways to create/link the same user
3. Keep the app’s session separate from the identity provider
4. Make account linking explicit and safe

Here’s a practical design.

---

Recommended architecture

1) Use your own user account in the backend

Have one internal user record, for example:

• users
• auth_identities or login_methods

A user can have multiple login methods:

• Apple Sign In
• Email/password

Example schema idea:

• users
  • id
  • display_name
  • created_at
• user_identities
  • id
  • user_id
  • provider (apple, password)
  • provider_subject (Apple sub, or email identifier)
  • email
  • password_hash (only for password users)
  • email_verified
  • created_at

This lets one person sign in with Apple now and later add email/password, or vice versa.

---

Auth flow by login method

A) Apple Sign In flow

1. User taps Continue with Apple
2. App gets an Apple identity token / authorization code
3. Send it to your backend
4. Backend verifies Apple token signature and claims
5. Backend looks up:
   • existing identity by Apple sub
   • or existing user by verified email, if appropriate
6. Backend creates or logs in the user
7. Backend returns your app session token

Important: Use Apple sub as the stable Apple identity key, not email.
Apple email may be private relay or may change visibility.

---

B) Email/password flow

1. User enters email/password
2. App sends credentials to backend over HTTPS
3. Backend:
   • validates password hash
   • checks account status
   • issues app session token
4. If no account exists:
   • create user
   • send verification email
   • optionally allow limited access until verified

Important: store only password hashes, never plaintext. Use a strong password hash like Argon2id or bcrypt.

---

Account linking strategy

This is the part that matters most.

Best practice: explicit linking

If a user is already signed in and wants to add another login method:

• signed in with Apple → add email/password
• signed in with email/password → add Apple

Flow:

1. User is authenticated
2. They choose “Add email/password” or “Connect Apple”
3. Require a recent auth confirmation if sensitive
4. Add the new identity to the existing user record

This avoids accidental account merging.

---

Handling “same person” across login methods

You have three common cases:

Case 1: Apple sign-in first, then email/password later

• Create user from Apple
• Later user sets password in settings
• Link password identity to same user

Case 2: Email/password first, then Apple later

• User signs in normally
• In settings, they tap Apple sign-in
• Backend links Apple sub to same user

Case 3: User tries Apple and email and has two accounts

Do not auto-merge silently.

Instead:

• detect potential duplicate accounts
• ask the user to choose:
  • keep separate
  • merge after confirming both methods

For merging, require strong proof:

• verify current session
• verify ownership of the second login method
• possibly verify email codes

---

Apple-specific considerations

1) Hide email

Apple may return:

• real email
• private relay email
• no email on subsequent logins

So you should not rely on email as the identity key.

2) Name is only provided once

Apple typically provides the user’s name only on first authorization. Store it immediately if you need it.

3) Email verification

If Apple provides an email, it is considered verified by Apple, but still don’t use email alone as the stable account identity.

4) Account deletion

If your app allows account creation with Apple, Apple often expects you to support account deletion from within the app if you have user accounts.

---

Session design

Use your own app session tokens

After login, issue:

• short-lived access token
• refresh token, if needed

Store tokens securely:

• iOS Keychain
• Android Keystore / secure storage

Do not use Apple tokens as your long-term app session.

---

Signup/login UX recommendation

A simple UX works best:

Main screen

• Continue with Apple
• Continue with email
• Sign in

Email flow

• “Create account” and “Sign in” can be combined
• If email not found, create account after password set
• If found, authenticate

During first-time Apple sign-in

• create account automatically
• then prompt to add a password optionally:
  • “Want a backup login method? Add email/password.”

This improves account recovery.

---

Account recovery

If you support email/password, build recovery into it:

• password reset email
• email verification
• change email flow
• recent login required for sensitive actions

If a user only has Apple login, recovery depends on Apple.
That can be okay, but many apps still encourage adding a backup email/password login.

---

Security checklist

• Verify Apple tokens on the backend
• Use HTTPS everywhere
• Hash passwords with Argon2id or bcrypt
• Rate limit login and password reset endpoints
• Use secure storage on device
• Support MFA if your risk level warrants it
• Log auth events for fraud detection
• Never trust client-provided identity data without backend verification

---

A good practical rule

One user = one backend account, many login methods.

That gives you:

• Apple login
• email/password login
• linking/unlinking
• fewer duplicate accounts
• easier recovery

---

Suggested implementation pattern

Backend endpoints

• POST /auth/apple
• POST /auth/login
• POST /auth/register
• POST /auth/link/email
• POST /auth/link/apple
• POST /auth/password/reset-request
• POST /auth/password/reset-confirm
• POST /auth/logout

App states

• unauthenticated
• signed in
• needs email verification
• needs account linking
• needs re-auth for sensitive action

---

If you want, I can also sketch:

1. a database schema,
2. an API design, or
3. a step-by-step login/linking flowchart for Apple + email/password.