Inconsistent Firestore Access with Custom Claims After getIDTokenForcingRefresh(true)

[HyenaJeremyLin]

Description

I encountered an issue related to Firestore access when using custom claims in our iOS app. Here’s the situation:

1. Our app calls our server’s API, where the admin sets a custom claim "pair_id" of type String for the user.
2. After the API call is complete, the app calls getIDTokenForcingRefresh(true) to refresh and retrieve the updated token, which includes the "pair_id" claim.
3. However, when attempting to access Firestore immediately after obtaining the refreshed token, our access is denied based on the security rules.
4. Interestingly, if we attempt to access Firestore again after waiting for around 5 seconds, it succeeds without issues.

It seems there is a delay in Firestore recognizing the updated custom claims. Is there a recommended way to adjust this behavior or a workaround to ensure Firestore permissions work immediately after refreshing the token?

I also came across this issue: #1499 Is re-authenticating the only solution for now?

Reproducing the issue

No response

Firebase SDK Version

10.22.1

Xcode Version

16.0

Installation Method

Swift Package Manager

Firebase Product(s)

Firestore

Targeted Platforms

iOS

Relevant Log Output

No response

If using Swift Package Manager, the project's Package.resolved

Expand Package.resolved snippet

Replace this line with the contents of your Package.resolved.

If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet

Replace this line with the contents of your Podfile.lock!

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[tom-andersen]

Hi @HyenaJeremyLin!

After discussing with @dconeybe, we have a working theory. If you can try our suggestion, please let us know if it works.

1. Yes, there is a delay. The SDK Auth component is separate from Firestore component. The communication between Auth and Firestore is asynchronous, such that a token refresh will arrive shortly after forcing it.
2. Normally, when Auth notifies Firestore of User token change, Firestore will disconnect and reconnect with new token.
3. Instead of waiting for Auth to notify Firestore, you can force reconnection by using Firestore disable/enable network methods.

See: https://firebase.google.com/docs/firestore/manage-data/enable-offline#disable_and_enable_network_access

Please try following steps:

1. Call getIDTokenForcingRefresh(true) as before.
2. Then disable network.
3. Then enable network.
4. Access document.

This should have the desired effect.

[google-oss-bot]

Hey @HyenaJeremyLin. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[marinofelipe]

Hi @HyenaJeremyLin!

After discussing with @dconeybe, we have a working theory. If you can try our suggestion, please let us know if it works.

1. Yes, there is a delay. The SDK Auth component is separate from Firestore component. The communication between Auth and Firestore is asynchronous, such that a token refresh will arrive shortly after forcing it.
2. Normally, when Auth notifies Firestore of User token change, Firestore will disconnect and reconnect with new token.
3. Instead of waiting for Auth to notify Firestore, you can force reconnection by using Firestore disable/enable network methods.

See: https://firebase.google.com/docs/firestore/manage-data/enable-offline#disable_and_enable_network_access

Please try following steps:

1. Call getIDTokenForcingRefresh(true) as before.
2. Then disable network.
3. Then enable network.
4. Access document.

This should have the desired effect.

@tom-andersen , thanks for the reply.

I'm replying to you, because I'm facing a similar issue at work. The use case is very similar to the one reported by @HyenaJeremyLin, but instead of trying to access Firestore we just call getIDTokenResult(:forcingRefresh true) and the token doesn't have the claims updated. We need the token with the latest claims to communicate with our BE.

The work-around I found was to refresh the token with a delay, after 0.3 seconds or so, which is quite fragile and problematic imo. Now that I read your reply, I tried the approach suggest by you, but it unfortunately did not work.

A few follow up questions:

• Have this changed in the major bump from version 10.* to 11.*? For us, it works fine without the bump, although I see @HyenaJeremyLin said for them it fails on the Firebase SDK Version 10.22.1 🤔
• Would it be possible to handle that inside the SDK? For example, there could be an async overload where the SDK delays the refresh and/or waits for claims to be updated. I reckon that is far from simple and might not be possible given it depends on the server and the client SDK is likely agnostic of it(?), but if everyone has to do manual tricks to asynchronously refresh the token, it might be better to have the SDK simplify that instead

[marinofelipe]

Actually, even with the "manual" delay, it's not quite working 😢. It only works after the user gets signed out, which is a side effect of the 401 I get for the lack of the custom claim (our internal logic).

I also see the following logs before the claim starts to appear

attempted to run migration and failed. closing connection.
attempted to run migration and failed. closing connection.
attempted to run migration and failed. closing connection.

Which look like some internal Firestore calls (?)

[tom-andersen]

@marinofelipe Your question might be better directed towards someone from api: auth, since it doesn't involve Firestore (if I understand correctly). In which case, you might want to start new issue with reference to this issue for context.

I think what you desire, "there could be an async overload where the SDK delays the refresh and/or waits for claims to be updated", is done in Firestore by use of FIRAuthStateDidChangeInternalNotification. Someone who knows more about auth could help you get access to this notification. But that should be asked as a new issue, since it doesn't relate to Firestore.

[marinofelipe]

Hi @tom-andersen , it make sense. I assumed they were related. I'll do as you say and create a new issue attributed to auth, thank you!