Technologies / Identity
Authentication and SSO for mobile apps, built to current standards
Authentication and SSO for mobile apps decide two things at once: how many people finish sign-up, and how exposed your users are when something goes wrong. The rules are stricter than on the web. Apple has a specific guideline on login options, the OAuth standard for native apps forbids patterns many tutorials still use, and passkeys now let you drop passwords on both iOS and Android.
Below we cover consumer social login, passkeys and workforce SSO. Identity is one of the building blocks in our mobile app development technologies hub.
- Login options checked against Guideline 4.8
- OAuth in the system browser with PKCE
- Passkeys on iOS and Android
- Identity provider accounts in your name
Apple Guideline 4.8: what login options iOS apps must offer
Many teams still believe that adding Google or Facebook login forces you to add Sign in with Apple. That was true until Apple changed the rule on 26 January 2024. The current wording of Guideline 4.8 Login Services says that if an app uses a third-party or social login (such as Google, Facebook, X, LinkedIn, Amazon or WeChat) for the primary account, it must also offer an equivalent login service that:
- limits data collection to the user’s name and email address,
- lets users keep their email address private, and
- does not collect interactions with the app for advertising without consent.
Sign in with Apple meets all three, so it remains the simplest way to comply, but it is no longer the only one. The rule does not apply if the app uses only your company’s own account system, education or enterprise accounts, government or citizen e-ID, is a client for a specific third-party service, or uses an alternative-marketplace login.
Remember the related rule: apps that let users create an account must also let them delete it from within the app, under Guideline 5.1.1(v).
Passkeys: password-free sign-in on both platforms
Passkeys replace passwords with public-key credentials unlocked by Face ID, Touch ID, a fingerprint or the device PIN. There is nothing to phish and nothing to reuse across sites, and support desks get fewer password-reset tickets.
On iOS
Passkeys are stored in iCloud Keychain. The app needs an associated domain with the webcredentials service, which ties the app to your website so the same passkey works in both. Passkey availability checks inside WKWebView need iOS 16.4 or later, per Apple’s passkeys documentation.
On Android
Credential Manager supports passkeys on Android 9 (API 28) and higher. It is built on WebAuthn, passkeys sync across devices including Windows and iOS, and it also works on Wear OS and Android XR.
We usually offer passkeys alongside email or social sign-in rather than as the only option, and prompt users to create one after a successful login. Account recovery still needs a planned route, such as a verified email, because users replace phones.
OAuth for native apps: the rules that prevent account takeover
If your app signs users in through an identity provider (Google, Microsoft, Okta, Auth0, Cognito or your own), the IETF standard for native apps applies.
| Standard | What it requires | Why it matters |
|---|---|---|
| RFC 8252 / BCP 212 (OAuth 2.0 for Native Apps) | Native apps must not use embedded web views for authorization; use the system browser | An embedded view lets the app read the user’s password and breaks the shared browser session |
| RFC 8252 redirects | Private-use URI scheme, claimed https link, or loopback redirect | Claimed https links (Universal Links, App Links) are hardest for another app to intercept |
| RFC 7636 (PKCE) | One-time code verifier and code challenge; required for public native clients under RFC 8252 | An intercepted authorization code cannot be redeemed by a malicious app |
| No client secrets in the app | Mobile apps are public clients | Anything shipped in the binary can be extracted |
Sources: RFC 8252 and RFC 7636 at rfc-editor.org.
How we implement OAuth and tokens
We follow RFC 8252: sign-in opens in ASWebAuthenticationSession on iOS and Custom Tabs on Android, both of which use the system browser, with PKCE on every authorization code exchange. Libraries such as AppAuth handle most of this correctly, so we avoid writing the protocol by hand.
After sign-in, access tokens stay short-lived. Refresh tokens are stored in the iOS Keychain or Android Keystore-backed storage, never in plain preferences, and rotated on use where the provider supports it. Logout revokes tokens on the server, not just on the device. For sensitive actions, such as changing a payout account, we ask for re-authentication or biometrics. Account security checks map to the MASVS-AUTH group of the OWASP mobile standard, and we test against it on our mobile app security testing service.
Choosing between social login, passkeys and SSO?
Tell us who your users are and which accounts they already have. Within one business day we reply with a recommended sign-in mix, the store rules that apply and the identity provider we would use.
Choosing an identity approach
Most apps combine two or three of these. The table shows where each fits.
| Approach | Best for | Trade-offs |
|---|---|---|
| Email and password with MFA | Universal fallback; markets where social accounts are less common | Password resets and credential stuffing to defend against |
| Social login (Google, Apple, Facebook) | Consumer apps that need fast sign-up | Guideline 4.8 equivalent-login rule on iOS; dependence on the provider |
| Passkeys | Consumer and business apps that want phishing-resistant sign-in | Recovery flow still needed; some users are unfamiliar with them |
| Phone number and OTP | Markets and audiences where a phone number is the main identity | SMS cost and SIM-swap risk; avoid for high-value accounts alone |
| Enterprise SSO (OIDC or SAML via Microsoft Entra ID, Okta, Google Workspace) | Internal and B2B apps used by employees | Per-customer configuration; exempt from Guideline 4.8 as enterprise accounts |
| Managed identity services (Firebase Auth, Cognito, Auth0, Supabase Auth) | Teams that want auth without building it | Usage-based pricing at scale; migration effort if you leave |
Firebase Authentication supports email and password, phone, federated providers, custom auth and anonymous accounts.
Enterprise SSO for internal and B2B apps
Business apps should sign employees in with the accounts they already use. We connect apps to the customer’s identity provider over OpenID Connect, or SAML through a broker where the provider only speaks SAML. That gives the customer’s IT team control: they disable a leaver once and access ends everywhere.
B2B SaaS apps often need SSO per customer. We build tenant discovery (the user types a work email, the app routes to the right provider), map roles from identity-provider groups, and keep an admin screen for configuration. This work sits close to our enterprise mobile app development and internal employee app services, and the server side lives in your mobile app backend.
Hiring and maintenance implications
Authentication bugs are security bugs, so we keep this work with senior developers who have implemented OAuth and token storage before, and we review it as a separate pull request. Using a managed identity service such as Firebase Authentication or Supabase Auth reduces the code you own, but not the need to configure it carefully.
Maintenance involves provider SDK updates, signing-key rotation, redirect-domain changes and store rule changes like the 2024 revision of Guideline 4.8. Each OS release also tends to adjust credential and passkey APIs. We cover this in app maintenance and support.
Authentication checklist before release
What we verify on every app with user accounts.
- Login options meet the current Guideline 4.8 wording
- In-app account deletion available (Guideline 5.1.1(v))
- OAuth through the system browser, never an embedded web view
- PKCE on every authorization code exchange
- No client secrets shipped in the app binary
- Tokens in Keychain or Keystore-backed storage, short-lived access tokens
- Server-side logout and token revocation
- Passkey associated domains configured and tested
- Rate limiting and lockout on password and OTP endpoints
- Re-authentication for sensitive account changes
Authentication and SSO for mobile apps: frequently asked questions
Do we still have to add Sign in with Apple if we offer Google login?
Not necessarily. Since 26 January 2024, Guideline 4.8 requires an equivalent login service that limits data to name and email, lets users hide their email and does not track them for ads without consent. Sign in with Apple meets that and is the easiest choice, but another qualifying service is allowed. Some apps are exempt entirely.
Should our app support passkeys?
For most new apps, yes, alongside another sign-in method. Passkeys are phishing-resistant and remove password resets. Apple stores them in iCloud Keychain, and Android Credential Manager supports them on Android 9 and higher, syncing across devices. You still need a recovery route, such as a verified email, for users who lose every device.
Why can’t we show the login page in a web view inside the app?
RFC 8252, the IETF best practice for OAuth in native apps, says native apps must not use embedded web views for authorization. An embedded view lets the app see the user’s credentials and loses the browser’s existing session. Using the system browser through ASWebAuthenticationSession or Custom Tabs is safer and often faster for users already signed in.
What is PKCE and do we need it?
PKCE, defined in RFC 7636, adds a one-time code verifier and challenge to the OAuth flow, so an intercepted authorization code is useless to another app. RFC 8252 requires it for public native clients, which includes every mobile app. Most identity providers and libraries support it; we enable it on every integration.
Can our app use our company’s Microsoft or Okta accounts?
Yes. We connect to Microsoft Entra ID, Okta, Google Workspace or other providers over OpenID Connect, or SAML through a broker. Employees sign in with existing accounts, IT controls access centrally, and leavers lose access when their account is disabled. Enterprise accounts are exempt from Apple’s equivalent-login rule.
Is phone number login with OTP secure enough?
For low-risk consumer apps in markets where phone is the main identity, it is a reasonable primary method. SMS codes are vulnerable to SIM-swap and interception, so for payments, health data or account changes we add a second factor, a passkey or device biometrics. We also rate-limit OTP requests to control fraud and SMS costs.
Design sign-in that is easy for users and hard for attackers
Book a 30-minute scoping call. We will map your user types, the store rules that apply and the identity provider and standards we would build on.