Do I need separate auth for web and mobile?

Not always — but often, yes in practice, depending on how your app is built.

Short answer

• If web and mobile use the same backend/API, you can usually use the same auth system.
• If they have different login flows, storage, or security needs, you may need separate implementation details even if the underlying identity system is shared.

Common setup

A good pattern is:

• One identity provider / auth backend
• Different client handling
  • Web: cookies / session or OAuth redirect flow
  • Mobile: token-based flow using PKCE, storing tokens in secure storage

When you can share auth

You can often reuse the same auth if:

• Same user accounts
• Same backend
• Same permissions/roles
• Same SSO provider (e.g. Auth0, Cognito, Firebase Auth, Azure AD)

When you should split or customize

You may want different auth approaches if:

• Web uses cookie sessions and mobile uses bearer tokens
• Mobile needs biometrics / device binding
• You have different app clients with different scopes/permissions
• You want separate branding, policies, or token lifetimes
• You need to support in-app browsers, deep links, or app store requirements

Recommended architecture

Usually:

• Single user directory / auth service
• Separate client apps
• Same authorization logic on the API
• Client-specific login UX

Rule of thumb

• Same users + same API + same provider → shared auth system
• Different client security/storage patterns → separate client auth flows, not necessarily separate user systems

If you want, I can sketch the best setup for:

1. web + iOS/Android, or
2. SPA + mobile app + API.