Facebook Limited Login on iOS: Why Declining ATT Downgrades Your Users' Tokens
Your iOS app has not changed. Your Meta App Dashboard has not changed. But a growing share of your users now hit OAuthException — “Invalid OAuth access token — Cannot parse access token” — and every Graph API call behind that login fails. The cause is not your code. It is which login mode Meta silently routed those users into.
The short version
Apple's App Tracking Transparency (ATT) prompt decides which Facebook Login your iOS users get. Meta's own documentation is explicit about it: from Facebook iOS SDK v17.0.0, the SDK no longer provides valid user access tokens in scenarios where the user opts out of ATT, and when users opt out, all Facebook Login traffic is performed on the Limited Login domain.
That is not a soft degradation. It is a different token type, a different host, and a materially smaller set of things your app is allowed to do — applied per device, without any change on your side.
The failure most teams misdiagnose
Teams see the OAuth error and start rotating app secrets, re-checking redirect URIs, or resubmitting for App Review. None of that is the problem. The token was never an access token to begin with — it is an OpenID Connect ID token, and the Graph API will never accept it.
Classic Login vs Limited Login: what actually differs
| Classic Facebook Login | Limited Login | |
|---|---|---|
| What you receive | OAuth 2.0 user access token | AuthenticationToken wrapping an OpenID Connect ID token (a JWT) |
| Graph API requests | Supported | Fail — there is no access token to send |
| Page tokens / session info tokens | Obtainable | Cannot be obtained from the ID token |
| Business permissions | Supported | Not supported |
| Login host | facebook.com | limited.facebook.com |
| Fast app switch to the Facebook app | Supported | Not supported — login happens in an in-app browser |
| Permission removal endpoint | /me/permissions | Separate uninstall endpoint on the limited domain |
Meta's Limited Login documentation states the ID token “cannot be used to request additional data using the Graph API, such as friends, photos, or pages, and it cannot be used to get other tokens.” Doing any of that requires classic Facebook Login — which, in Meta's own wording, “does not support Limited Login safeguards.”
Four ways this breaks a real product
1. Every Graph call behind the login dies
Profile enrichment, page reads, posting, insights — anything that needs the Graph API returns an OAuth error for ATT-declining users, even though the login itself reported success.
2. Login for Business stops working
Meta's FAQ is direct: Limited Login does not support business permissions. If your iOS app uses Facebook Login for Business, ATT-declining users cannot complete that flow at all.
3. Your login UX quietly changes
No redirect into the Facebook app. Users get an in-app browser and are asked to type credentials — a measurable conversion drop that support tickets usually describe as “login looks broken.”
4. Your debugging tools go dark
The ID token is not an access token, so the usual token inspection and expiry checks do not apply. Validation has to happen against the OIDC discovery and JWKS endpoints instead.
What Limited Login still gives you
It is not a dead end. A successful Limited Login populates an AuthenticationToken and a shared profile instance containing an app-scoped ID (ASID), name and profile picture, plus email if the user granted it. Meta confirms fb_login_id (the ASID) is still present in Limited Login mode — it is the user access token that gets swapped for an OIDC token, not the identifier.
Meta's iOS documentation lists the permissions that can be requested in Limited Login, including public_profile, email, user_age_range, user_birthday, user_friends, user_gender, user_hometown, user_link, user_location and user_messenger_contact. Requesting a permission outside that scope simply fails to build a valid configuration.
An important nuance: even with user_friends approved, Limited Login returns app-scoped IDs for friends rather than a normal friends payload — and Meta asks that you do not turn those ASIDs into Graph API calls, because doing so strips the Limited Login safeguards from users who never agreed to tracking.
The decision your team actually has to make
This is a product and compliance decision before it is an engineering one, and it is where most iOS integrations get stuck.
Decide what your app genuinely needs after sign-in
Identity only, or ongoing Graph API access? The answer determines whether Limited Login is sufficient or whether you need a dual-path design. Getting this wrong forces a rewrite later.
Work out what happens to ATT-declining users
You cannot force ATT consent, and you should not design as if everyone accepts. A defensible product answer is required for the share of users who decline — degraded feature, alternative flow, or a clearly explained limitation.
Separate identity handling from data access
Server-side validation of an OIDC ID token is a different code path from validating an access token, with different endpoints and different trust assumptions. Treating them as interchangeable is the most common architectural mistake here.
Re-check your App Review demo
Meta reviewers test on real devices. If your reviewer instructions assume the classic flow and the reviewer's device lands in Limited Login, your demo shows an app that appears to fail — a rejection reason that has nothing to do with the permission you applied for.
Align your privacy disclosures with the mode you ship
Switching a user to tracking-enabled classic login to obtain an access token has disclosure consequences. Meta states plainly that in that path, users are tracked and Limited Login safeguards do not apply.
Where teams get stuck
- Assuming it is an App Review problem. It is an SDK and platform-behaviour problem. Resubmitting does not fix it.
- Testing only on a device that accepted ATT. The Limited Login flag is device-specific, not account-wide, so a single test device proves nothing about the other path.
- Shipping Login for Business on iOS without a fallback. Business permissions are simply unavailable in Limited Login; the flow has to exist elsewhere — web, Android, or classic iOS login.
- Forgetting existing users. Already-logged-in users are unaffected until they are logged out, which hides the problem in staging and surfaces it in production.
- Assuming tvOS parity. Meta states Limited Login is not available for tvOS at this time.
- Writing a privacy policy that describes only one of the two flows. This is a frequent, avoidable App Review finding.
How this connects to the rest of your Meta setup
Limited Login sits on top of decisions you have already made elsewhere in your Meta app. Which permissions you request, and whether they need App Review at all, is covered in Facebook Login permissions and when email and public_profile are not enough. If your integration is business-facing, the split between the two login products matters even more — see Facebook Login for Business vs Facebook Login and the configuration mechanics in why config_id replaces scope and what App Review checks.
Getting help with this
Diagnosing a Limited Login problem means separating three things that look identical from the outside: an SDK behaviour change, a permission that was never approved, and an App Review demo that fails on the reviewer's device for an unrelated reason. We provide App Review preparation and policy-aligned technical guidance for Meta integrations, including iOS login-mode reviews and submission support. No specific review outcome can be promised — Meta decides that — but a submission that documents both login paths correctly removes the most common avoidable rejection.
Sources: Meta for Developers — Limited Login overview (updated 28 Mar 2024), Limited Login for iOS (updated 2 Sep 2021), OIDC Token for Limited Login (updated 28 Mar 2024), and Limited Login FAQ (updated 28 Feb 2025). Platform behaviour changes; verify against Meta's current documentation before implementation.