Notifications
Clear all
Topic starter
08/06/2026 4:27 pm
TL;DR: Apple’s 2025 App Store guidance requires apps that offer third-party social login to also provide an equivalent privacy-focused option, usually Sign in with Apple, and the article shows how to wire that into an iOS flow with OAuth 2.0 PKCE using WorkOS AuthKit. The control issue is not login convenience, but whether mobile identity design satisfies platform policy without shipping secrets or relying on insecure browser handling.
NHIMG editorial — based on content published by WorkOS: How to add auth to your Apple app in order to be listed in the Apple Store in 2025
Questions worth separating out
Q: How should security teams implement social login in an iOS app without failing App Review?
A: Use Sign in with Apple wherever third-party login is offered, and keep the flow inside a secure system browser with OAuth 2.0 PKCE.
Q: Why do mobile apps need PKCE even when they already use an identity provider?
A: PKCE protects the authorization code exchange from interception and removes the need to embed a long-lived client secret in the app.
Q: What breaks when an iOS app ships secrets inside the client code?
A: Any secret embedded in the app should be treated as exposed, because attackers can extract it from the binary or runtime.
Practitioner guidance
- Inventory every social login path before App Review Document whether each provider is paired with Sign in with Apple or another Apple-compliant equivalent, and confirm the app’s authentication story is consistent across all login entry points.
- Use OAuth 2.0 Authorization Code with PKCE for every native login Generate the code verifier locally, derive the challenge with SHA-256, and complete the token exchange only after the browser session returns an authorization code.
- Keep credentials out of the mobile binary Store API keys and client identifiers as managed secrets outside the app code path, and reject any implementation that relies on a shipped client secret for sign-in.
What's in the full article
WorkOS's full article covers the implementation detail this post intentionally leaves for the source:
- Step-by-step iOS code for ASWebAuthenticationSession and the PKCE code challenge flow
- Dashboard configuration details for redirect URIs, logout redirects, and provider setup
- Apple developer account fields required for Sign in with Apple, including Team ID and Service ID
- Token exchange request examples and response handling for access and refresh tokens
👉 Read WorkOS's guide to Apple app authentication and OAuth PKCE →
Sign in with Apple and social login compliance for iOS apps?
Explore further
08/06/2026 6:06 pm
Mobile authentication is now a platform governance problem, not just an app feature. Apple’s rules force teams to prove that third-party login has an equivalent privacy-safe path and that the native flow uses secure browser-based authorization rather than embedded shortcuts. That moves mobile IAM into the same governance conversation as federation policy, token handling, and reviewability. Practitioners should treat app-store authentication as a control boundary, not a developer convenience.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control.
A question worth separating out:
Q: How should teams handle logout and token revocation in mobile identity flows?
A: Teams should invalidate the server-side session, redirect users through the configured logout path, and remove access and refresh tokens from secure storage such as Keychain. This prevents stale credentials from remaining usable after the user thinks they have signed out. Logout should be tested as a control, not assumed to work because the UI changed.
👉 Read our full editorial: Apple app authentication in 2025: social login compliance rules
