auth.useUserAccessGroup(accessGroup) does not work to share authentication between Watch and iPhone

[RohitRajendran]

[REQUIRED] Step 1: Describe your environment

• Xcode version: Version 12.4
• Firebase SDK version: 7.9.1
• Installation method: Swift Package Manager
• Firebase Component: Auth

[REQUIRED] Step 2: Describe the problem

Steps to reproduce:

I'm trying to use Auth.auth().useUserAccessGroups across both iPhone and WatchOS apps to share authentication. The iPhone app initiates an anonymous sign in and should be sharing the user but the watch app returns nil.

1. Setup an iPhone and WatchOS app and follow the following steps for cross app authentication https://firebase.google.com/docs/auth/ios/single-sign-on?authuser=0. I set up an app group and used that in both the iphone and watch app.
2. In the iphone app, on init, utilize signInAnonymously after calling Auth.auth().useUserAccessGroup
3. In the watch os app, on init, check the currentUser value after calling Auth.auth().useUserAccessGroup
4. Run the iphone app and then the watch os app. The watch os app will return nil for user

Relevant Code:

In iPhone app:

init() {
        FirebaseApp.configure()

        do {
            Auth.auth().shareAuthStateAcrossDevices = true
            try Auth.auth().useUserAccessGroup("APP_GROUP_NAME")
        } catch let error as NSError {
            print("Error changing user access group: %@", error)
        }

        if Auth.auth().currentUser === nil {
            Auth.auth().signInAnonymously()
        }
        
        print(Auth.auth().currentUser?.uid, "user")
    }

In watch app:

init() {
        FirebaseApp.configure()

        do {
            Auth.auth().shareAuthStateAcrossDevices = true
            try Auth.auth().useUserAccessGroup("APP_GROUP_NAME")

            print(Auth.auth().currentUser?.uid, "user")
        } catch let error as NSError {
            print("Error changing user access group: %@", error)
        }
    }

[rizafran]

Hi @RohitRajendran, would you mind sharing a minimal repro that I can run locally? It would help us a lot digging into the cause of your issue. Thanks.

[google-oss-bot]

Hey @RohitRajendran. 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!

[google-oss-bot]

Since there haven't been any recent updates here, I am going to close this issue.

@RohitRajendran if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this.

[paulb777]

Reopening based on conversation in #7840.

Note that watchOS is community supported so it may be awhile before anyone gets to this.

[dweekly]

Thanks for re-opening, Paul.

It would be good to have a "best practices for watchOS + iOS Firebase apps" doc that lives somewhere, even community-supported and with huge asterisks that it's not official yet.

I think there are a few options:

1. Pass a Token
   Have the iPhone perform the auth flow and then retrieve a current token via Auth.auth().currentUser.getIDToken, then pass the token to the watch via a WCSession updateApplicationContext on session activation. Until the watchOS app receives the app context, it will have to display a "please log in on your iPhone" message to the user. This has the advantage of not actually requiring FirebaseAuth on the watchOS client at all - the watch app can just use the token in e.g. server API calls directly. The iOS app will be responsible for keeping its watch companion updated as the token renews and the watchOS app may need to enquire about a new token with the iOS parent app if it hears back that the token has expired.

The disadvantage of this approach is that it does not allow for a standalone watchOS app; the watch can only be used as a companion to the iOS app. In reality, very few apps are - or need to be - standalone; the watchOS App Store is a bit of a joke. So this should be fine for most developers.

2. iCloud Keychain Sync
   Use a group/shared keychain between apps and enable iCloud Keychain synchronization, then direct Firebase Auth to use this shared keychain. In theory this enables all of a user's devices that are signed in with their iCloud account to also now be signed in with Firebase as the same user.

I haven't gotten this approach working yet but in theory it could/should work and it enables a full "acts like a peer" approach for watchOS as a client that enables an independent watchOS app experience. The phone and watch don't need to be communicating directly for this to work either; e.g. if the watch has a cellular connection it should be able to complete the iCloud sync.

3. Proxy
   Have the iOS app pull all required data for the watchOS app and send it as app State. When the watchOS app opens, have it request information from (and send information to) the iPhone via WCSession messages.

This has the advantage of allowing for a much simpler and smaller watchOS client - the client never makes any "network" requests at all, just chatting with the host iOS app. No Firebase on-watch! The iOS app can use more sophisticated protocols like gRPC to talk to server backends to fulfill the request, none of which the watchOS app needs to be worried about. And the iOS app can just re-use existing code paths already needed to implement these things. The disadvantage is that all operations must be done in actively paired mode; the watchOS app will stop working altogether without an active WCSession, so the watch can never be far from the phone. That's probably an acceptable tradeoff for most apps.

4. [DOESN'T WORK] App Group

It should be made clear to developers that setting up an app group for their watchOS extension and iOS app and then asking Firebase Auth to use that app group will NOT magically allow Firebase Auth to work correctly on-watch because app groups are used for on-device sharing and the watch and phone are separate devices. Clearly spelling this out will save developers heartache trying to figure out what's wrong.