The accessToken generated by SDK 17.0.0 is Invalid: Invalid OAuth access token - Cannot parse access token

[alwayswith]

Checklist before submitting a bug report

• I've updated to the latest released version of the SDK
• I've searched for existing GitHub issues
• I've looked for existing answers on Stack Overflow, the Facebook Developer Community Forum and the Facebook Developers Group
• I've read the Code of Conduct
• This issue is not security related and can safely be disclosed publicly on GitHub

Xcode version

15.2

Facebook iOS SDK version

17.0.0

Dependency Manager

SPM

SDK Framework

Login

Goals

I had upgrade the sdk to 17.0.0, but access token generated by the sdk is invalid. I used the Graph API Explorer to debug the access token, It reports error.
When I downgrade the sdk verstion to 16.3.1, the access token is valid.

Expected results

{
"id": "123456",
"name": "Zac"
}

Actual results

{
"error": {
"message": "Invalid OAuth access token - Cannot parse access token",
"type": "OAuthException",
"code": 190,
"fbtrace_id": "A5WdWSSFlOkAu4p8C-qJGqR"
}
}

Steps to reproduce

No response

Code samples & details

// get the access token
  let loginButton = FBLoginButton()
        loginButton.center = view.center
        view.addSubview(loginButton)
        
        DispatchQueue.main.asyncAfter(deadline: .now() + 3) {
            if let token = AccessToken.current,
                !token.isExpired {
                print(token.tokenString)
            }
            // your code here
        }

[y2ducky]

I've encountered the same issue (I'm using Cocoapods). When using version 16.3.1, there are no errors, but upon upgrading to 17.0.0, I receive the "Invalid OAuth access token - Cannot parse access token" error when verifying the token in my server. In my testing, I've noticed that the tokenString value in version 17.0.0 is one character shorter than when testing with version 16.3.1. I'm not certain if this is related to the problem, but I thought it worth sharing.

• Updated:
  I have realized that it was intended behavior in version v17.0.0 and I resolved it by switching to the Limited Login method, which uses a JWT authentication token.

[KovtunOleg]

Debug-Token api will also fail with the same error for access tokens generated with iOS v17.0.0.

[jiwooong]

I've encountered the same issue. when using v16.3.1, there are no errors, but after update v17.0.0 I receive the same error. "Invalid OAuth access token - Cannot parse access token"

[HaejungAhn]

same here🥲

[goleoh]

Same. But it happened only at the M2 machines like a macbook pro. And I didn't use the limited login, but the browser opens for limited login. The url is like "limited.facebook.com". At the old facebook sdk, the opened url is like "m.facebook.com/".

And the returned token doesn't begin with "GG". Our app is a game, and the access tokens begin with "GG" usually.

[cxxer]

Same. But it happened only at the M2 machines like a macbook pro. And I didn't use the limited login, but the browser opens for limited login. The url is like "limited.facebook.com". At the old facebook sdk, the opened url is like "m.facebook.com/".

And the returned token doesn't begin with "GG". Our app is a game, and the access tokens begin with "GG" usually.

same. And there is no button that can be used to jump to the FB client.

[deepmode]

These are what I discover when using version 17.0.0 SDK with iOS 17+
With AppTracking Transparency enable for your App -> receive a valid FB AccessToken
With AppTracking Transparency disable for your App -> receive an invalid FB AccessToken

[zimssa-mkkim]

These are what I discover when using version 17.0.0 SDK with iOS 17+
With AppTracking Transparency enable for your App -> receive a valid FB AccessToken
With AppTracking Transparency disable for your App -> receive an invalid FB AccessToken

we have the exact same issue

[goleoh]

I resolved this issue. The FB SDK 17.0 uses a limited login forcefully in ios 17 when the ATT is not on. So we should impletemt limited logins. In the limited login, you cannot use the access token at the graph api in your web server. You can use the authentication token which is a JWT. You can verify it and extract user information from it. So you should handle the both tokens - normal access token on the ATT enabled and authentication token on the ATT not enabled. Or you can use the limited logins only and use authentication tokens.

[gonsee]

I have just found this announcement.
https://developers.facebook.com/blog/post/2024/03/28/changes-made-to-fb-login-sdk/

[AGulev]

I have just found this announcement. https://developers.facebook.com/blog/post/2024/03/28/changes-made-to-fb-login-sdk/

We got the same problem, so it's by design (not a bug)?
If so, this

I resolved this issue. The FB SDK 17.0 uses a limited login forcefully in ios 17 when the ATT is not on. So we should impletemt limited logins. In the limited login, you cannot use the access token at the graph api in your web server. You can use the authentication token which is a JWT. You can verify it and extract user information from it. So you should handle the both tokens - normal access token on the ATT enabled and authentication token on the ATT not enabled. Or you can use the limited logins only and use authentication tokens.

isn't a workaround but a proper solution for new SDK?

[beerana-meta]

Hello - We recently made changes to Facebook Login SDK for iOS. As a result of these changes, we recommend that you use Limited Login. If you are unable to implement Limited Login, the Graph API, iOS would need to be used to support these permissions. See more details here.

[jjw0722]

Hello - We recently made changes to Facebook Login SDK for iOS. As a result of these changes, we recommend that you use Limited Login. If you are unable to implement Limited Login, the Graph API, iOS would need to be used to support these permissions. See more details here.

Hello. then how to solve our problem?
We validate access token using our web server after facebook login. but now our app can't validate JWT iOS 17 device because we don't integrate limited login yet.

So you mean after all, in a system like us that verifies tokens through a web server, you can't do it the way it is, but you have to integrate limited logins or manually adjust the graph API?

Additionally, if you look at the official Facebook guide document, there is an article below, and even if you use that method, it returns an invalid access token. Why is that?

"A graph request will fail because there is no access token. To get an access token, either reuse the classic login method (defaults tracking to enabled), or call FBSDKLoginManager logInFromViewController:configuration:completion: with a configuration that specifies that tracking is enabled. Be aware that when you do this, users are tracked."

[ByBogon]

Hello - We recently made changes to Facebook Login SDK for iOS. As a result of these changes, we recommend that you use Limited Login. If you are unable to implement Limited Login, the Graph API, iOS would need to be used to support these permissions. See more details here.

Hello. then how to solve our problem? We validate access token using our web server after facebook login. but now our app can't validate JWT iOS 17 device because we don't integrate limited login yet.

So you mean after all, in a system like us that verifies tokens through a web server, you can't do it the way it is, but you have to integrate limited logins or manually adjust the graph API?

Additionally, if you look at the official Facebook guide document, there is an article below, and even if you use that method, it returns an invalid access token. Why is that?

"A graph request will fail because there is no access token. To get an access token, either reuse the classic login method (defaults tracking to enabled), or call FBSDKLoginManager logInFromViewController:configuration:completion: with a configuration that specifies that tracking is enabled. Be aware that when you do this, users are tracked."

which means web server can't validate JWT IOS 17 device through Facebook api?

Is there some way for web server to validate JWT IOS 17 device through Facebook api? OR should web server just decode and verify JWT IOS 17 device (authentication token) by this doc?

[jjw0722]

Hello - We recently made changes to Facebook Login SDK for iOS. As a result of these changes, we recommend that you use Limited Login. If you are unable to implement Limited Login, the Graph API, iOS would need to be used to support these permissions. See more details here.

Hello. then how to solve our problem? We validate access token using our web server after facebook login. but now our app can't validate JWT iOS 17 device because we don't integrate limited login yet.
So you mean after all, in a system like us that verifies tokens through a web server, you can't do it the way it is, but you have to integrate limited logins or manually adjust the graph API?
Additionally, if you look at the official Facebook guide document, there is an article below, and even if you use that method, it returns an invalid access token. Why is that?
"A graph request will fail because there is no access token. To get an access token, either reuse the classic login method (defaults tracking to enabled), or call FBSDKLoginManager logInFromViewController:configuration:completion: with a configuration that specifies that tracking is enabled. Be aware that when you do this, users are tracked."

which means web server can't validate JWT IOS 17 device through Facebook api?

Is there some way for web server to validate JWT IOS 17 device through Facebook api? OR should web server just decode and verify JWT IOS 17 device (authentication token) by this doc?

How to verify the Authentication Token on the web server is shown in the official guide document. What I said above is that the official guide document says that you can get an access token by setting the loginFromViewController API to tracking enabled as above, but even if you do that, you will return the invalid token and ask why.

You can get a JWT-type token from our web server and verify it, but I thought it could be solved by modifying the API without adding additional logic.

[ByBogon]

@jjw0722

Yep I got your point.
Just wondered whether I can use graph api to verify JWT, which is impossible.

So just to triple check, when web server validates JWT, gotta follow what the doc says, right?

[davehpcnt]

Facebook JWT tokens are not cached when the app is closed. Is there a way to get the token without displaying the limited login screen on Facebook?
FBSDKLoginKit.AccessToken.current?.tokenString -> nil?

[Yehsam23]

If ATT is not agreed upon, limited access will be imposed. Is there any way to retrieve the ID for business through JWT Token at this time?

[arkku]

Let's say I already have a nonce, how do I exchange it for a JWT token instead of the (broken) access_token?

[zimssa-mkkim]

When it's a limited login you can't use access token because graph api will not work with it. Instead, you can use FBSDK AuthenticationToken.currentAuthenticationToken and verify it with JWK verifiers.

[leonle69]

It's been over 3 weeks now and it hasn't been resolved. I am quite stressed about this issue. any idea how to resolve it?

[rgg-egunnery]

Has anyone gotten limited login to work with non tester accounts? Works fine for our test accounts but when trying to use it with public accounts, the new loginManager.logIn(configuration: configuration) just returns a cancellation. Not using anything that needs the app to be approved

[kevin-zqw]

When iOS ATT is disabled, even if I log in using the regular mode, the Facebook SDK will fall back to limited mode and return an invalid token.

Do you know how to determine if it's a limited login from the FBSDKLoginManagerLoginResult return result?

[mvpscottjon]

There two token in it

• one is accessToken which needs graphAPI to get user info

• another one is AuthenticationToken(aka JWT token) which needs JWT decode to get user info

If you use limit login, you only can get AuthenticationToken(Sorry I change to this. I said accessToken was wrong)

If you use enable tracking to login, you can get AuthenticationToken and accessToken(no matter ATT is enable or not...a little weird...)

[rgg-egunnery]

@mvpscottjon have you tried your .limited config with public accounts or just test accounts?

[Nathan-Molby]

@ankitpunchh You can just create that manifest inside your app and list all the reasons the 3-d party SDK is supposed to list. https://apnspush.com/create-privacy-manifest

But if you already had the app deployed, it won't even be a cause for rejection. It's a cause for rejection when you add new SDKs, if I'm not mistaken.

I hate to be the bearer of bad news, but this is not a good idea. The privacy manifest in Facebook version 17.0 describes the required reason APIs that Facebook uses in 17.0, not in 16.0. It is very likely that they have changed the required reason APIs that they use between 16.0 and 17.0, and as such, the privacy manifest would not be accurate.

Its unclear what the repercussions are for including an inaccurate privacy manifest, but you probably don't want to find out.

[Ariandr]

@Nathan-Molby
I don't think there could be any repercussions, since privacy-nutrition labels were there for years and if you got something wrong there, it wasn't a problem. You could be asked to clarify something, but not more.

[Ariandr]

@Nathan-Molby
Comes right from Apple.

[Nathan-Molby]

@Ariandr also straight from Apple. Our apps should not be including the privacy manifest from the SDKs -- the SDKs should include that themselves.

Obviously I can't speak to what the repercussions would be for doing this, but I'm not going to risk it.

[Ariandr]

@Nathan-Molby
"Doesn't need to cover" doesn't mean "cannot cover".

Lots of folks won't be able to update SDKs to latest versions because of technical reasons for some time, so it's okay that you include it in yours.

[Nathan-Molby]

@Ariandr but the problem is that we don't actually know what required reason APIs Facebook is using in version 16.0. Adding in the privacy manifest from 17.0 and then using SDK version 16.0 is inaccurate, and that inaccuracy might be a problem for Apple.

[Ariandr]

@Nathan-Molby
Okay, in that case they can ask you to pay attention to it and fix it. That's the worst they can do.

[phongth7]

Hi @beerana-meta

I'd like to know the limited login necessary if the user accepts Apple's App Tracking Transparency (ATT).
Is limited login only a single flow that may now be used to log in to Facebook for all cases?

Thanks,

[ankitpunchh]

Thanks @Nathan-Molby @Ariandr for the healthy discussion. Currently I will go with the easier solution of having manifest locally since we are bound to not upgrade limited login currently. Yesterday we published new app with the older facebook version and it got approved without any consequences.

But in future will definitely upgrade the fb SDK.

[XoL1507]

iPad2

[mariazhiriakova]

Hello everyone! I'm a backend developer and I've been following the discussion. It seems some of you are facing the same issue as me but I can't find a solution yet. Here's the situation:

Previously, our app used Facebook login. The exchange code would be sent to the server (handled by me), where I would swap it with Facebook for access and refresh tokens. These tokens were then stored, and the user was considered logged in. The following day, when the client app was opened, it would send a "is this person still logged in?" API request to the backend. I'd use the refresh token to renew the access token—if successful, I'd confirm the user is still logged in. If this failed, both the backend and client would assume the user has logged out and prompt a login screen again. This scenario was rare, often only occurring if a user removed our app’s permissions or had been inactive for an extended period.

With the switch to limited login, the process changed. I now receive a JWT, parse, and validate it—everything seems fine, and we consider the user logged in. However, 30 minutes later, the JWT remains unchanged, including its expiration, and I have no way of knowing whether the user has revoked app permissions. Relying solely on JWT expiration, users would need to sign in every 30 minutes, which is impractically frequent.

My question is: how should I determine if my users are still logged in? Should I integrate some logic with Facebook's servers, or perhaps set a custom expiration time, say, 30 days after the JWT was issued? Do you think it’s necessary to validate the account the next day, and if so, how?

[xsgoing]

There two token in it

• one is accessToken which needs graphAPI to get user info
• another one is AuthenticationToken(aka JWT token) which needs JWT decode to get user info

If you use limit login, you only can get AuthenticationToken(Sorry I change to this. I said accessToken was wrong)

If you use enable tracking to login, you can get AuthenticationToken and accessToken(no matter ATT is enable or not...a little weird...)

If ATT is disable, accessToken can not be used in graph api?

[ankitpunchh]

Hi @xsgoing , Yes you cannot use accessToken when ATT is disabled.

[ios-junghwan]

To my understanding, if my app is using graph API for facebook login, there's no way to implement limited login without server-side changes, am I correct?

1. If the user enables ATT -> use access token
2. If the user disables ATT -> there's no access token, validate the JWT and create user from server-side.

[mariazhiriakova]

To my understanding, if my app is using graph API for facebook login, there's no way to implement limited login without server-side changes, am I correct?

1. If the user enables ATT -> use access token
2. If the user disables ATT -> there's no access token, validate the JWT and create user from server-side.

That is exactly what I do and it works good. However - in the case of ATT disabled - what should I do the next day? Should I consider the user "signed in" forever?

[ankitpunchh]

To my understanding, if my app is using graph API for facebook login, there's no way to implement limited login without server-side changes, am I correct?

1. If the user enables ATT -> use access token
2. If the user disables ATT -> there's no access token, validate the JWT and create user from server-side.

Yes @ios-junghwan, You need some backend logic to get the values from that token.

[ankitpunchh]

To my understanding, if my app is using graph API for facebook login, there's no way to implement limited login without server-side changes, am I correct?

1. If the user enables ATT -> use access token
2. If the user disables ATT -> there's no access token, validate the JWT and create user from server-side.

That is exactly what I do and it works good. However - in the case of ATT disabled - what should I do the next day? Should I consider the user "signed in" forever?

Hi @mariazhiriakova , You can refer this stack overflow thread:

[jksmx]

There are approximately two solutions to address this issue:

1. Keep version 16.3. x and copy the content of the new version of PrivacyInfo.xcprivacy file to the privacy manifest file of the project, still using TrackingEnable mode and using FBSDKLoginManagerLoginResult. token. tokenString for GraphAPI verification.
2. Upgrading to version 17.0, whether enabled or limited, will result in a valid JWT file. The server will modify and verify the validity of the JWT, which is based on OIDC https://developers.facebook.com/docs/facebook-login/limited-login/token .

[xsgoing]

I got a new problem, when I use limited login, FBSDKLoginManagerLoginResult.iscancelled always be true

[phongth7]

I got a new problem, when I use limited login, FBSDKLoginManagerLoginResult.iscancelled always be true

Did you verify with both the normal and testing users? I remembered that it brought up additional [issues](https://github.com/facebook/facebook-ios-sdk/issues/2387).

[haryelramalho]

I resolved this issue. The FB SDK 17.0 uses a limited login forcefully in ios 17 when the ATT is not on. So we should impletemt limited logins. In the limited login, you cannot use the access token at the graph api in your web server. You can use the authentication token which is a JWT. You can verify it and extract user information from it. So you should handle the both tokens - normal access token on the ATT enabled and authentication token on the ATT not enabled. Or you can use the limited logins only and use authentication tokens.

But if you want a different permission not provided by limited login, what is the solution? I think that we don't have any :(

[evelant]

Is it possible to use the limited login flow for all users, not just via the ios sdk? I just need to get a JWT I can use for sign in with my backend. I don't need to do any graph api calls or anything. Right now the documentation is super vague. It doesn't tell us what the endpoints are or how we can use them, it just assumes the ios sdk is being used.

[phongth7]

Does anyone know why Facebook refuses to provide a rest API to simplify the validation of limited tokens? https://developers.facebook.com/docs/facebook-login/limited-login/token/validating/

[evelant]

Does anybody know why Facebook does anything at all? 😼 Sorry for the barb. It's frustrating. From an external developer's point of view trying to integrate with Facebook is super painful due to the vague docs, lack of consistent apis, and little communication/coordination.

[Rogue24]

Sorry, why was the updated iOS login method not synchronized in the iOS-related documentation (the old method's token verification always fails), but instead, the corresponding documentation was found through a link in an announcement? Integrating your SDK for the first time was really painful.

[bogpos]

Is this problem present in 17.1 SDK?