Handling user tokens and claims

[roomman]

Hi, I'm looking for a steer regarding how folk are dealing with Auth user tokens and custom claims in their apps.

Over the weekend I identified a bug in our app, whereby opening two browser sessions caused the restore() method in our custom authenticator to fire in a recursive loop. The culprit was some code we'd added into our authenticator to refresh the user token so we could capture any changes to a user's claims, those being fundamental to our Firestore security rules.

To fix this issue, we had to revert back to the original authenticator (the one provided by the addon) and create a service which polls the Auth user's token for changes, and updates the local session as required. This works but it seems like there would be a better way.

Can anyone shed some light and share their own approach to managing user claims?

---

Update

I'm just padding this question out with a bit more background and context, in case anyone has time to share their experiences.

Our ember-simple-auth custom authenticator is a very subtle modification of the base provided by this repo, and looks like this:

import { service } from '@ember/service';

import {
  getAuth,
  getIdTokenResult,
  getRedirectResult,
  onAuthStateChanged,
  signOut,
} from 'ember-cloud-firestore-adapter/firebase/auth';
import BaseAuthenticator from 'ember-simple-auth/authenticators/base';

import type SessionService from 'ember-simple-auth/services/session';
import type { Auth, IdTokenResult, User, UserCredential } from 'firebase/auth';

interface AuthenticateCallback {
  (auth: Auth): Promise<UserCredential>;
}

export default class FirebaseAuthenticator extends BaseAuthenticator {

  @service declare session: SessionService;

  public async authenticate(
    callback: AuthenticateCallback
  ): Promise<{ authUser: User | null; token: IdTokenResult | undefined }> {
    const auth = getAuth();
    const credential = await callback(auth);

    const token = await getIdTokenResult(credential.user, true);

    return { authUser: credential.user, token };
  }

  public invalidate(): Promise<void> {
    const auth = getAuth();

    return signOut(auth);
  }

  public async restore(): Promise<{ authUser: User | null; token?: IdTokenResult }> {
    return new Promise((resolve, reject) => {
      const auth = getAuth();

      const unsubscribe = onAuthStateChanged(
        auth,
        async (user) => {
          unsubscribe();

          if (user) {
            const token = await getIdTokenResult(user);

            resolve({ authUser: user, token });
          } else {
            getRedirectResult(auth)
              .then((credential) => {
                if (credential) {
                  resolve({ authUser: credential.user });
                } else {
                  reject();
                }
              })
              .catch(() => {
                reject();
              });
          }
        },
        () => {
          reject();
          unsubscribe();
        }
      );
    });
  }
}

The key difference is that we are returning the deserialised copy of the user's idToken along with the user.

We need this token so that we can manage access control by checking Custom Claims. For example:

{#if this.session.data.authenticated.token.claims.admin}
   <MyAdminComponent />
{else}
   <MyNonAdminComponent />
{/if}

The issue I'm having is how we refresh that token, as and when the claims change. For example, if we removed admin permissions from a user.

When manually calling this.session.session.restore() using the above Authenticator, we just get the local copy of the token with the expired claims. If I modify restore so that const token = await getIdTokenResult(user, true) (we are now forcing a refresh) I get a fresh token from the server along with the new claims. However, if I open a second browser tab, restore() / onAuthStateChanged is called in an infinite loop.

As a workaround, I created a service that gets a fresh token every fifteen minutes, compares the old and new claims, and calls this.session.session.restore() if changes are found. This results in restore() being fired ~40 times per browser session.

Is anyone else managing their tokens within their Authenticator? Can you share your approach?

If you think I'm mad and should be taking a totally different approach, please say 🤣

[mikkopaderes]

However, if I open a second browser tab, restore() / onAuthStateChanged is called in an infinite loop.

Not sure why this is the case, sounds like a bug in Firebase. If onAuthStateChanged is causing infinite loop, maybe you can try to do a super() rather than complete override of restore().

public async restore() {
  const user = await super();
  const token = await getIdTokenResult(user, true);

  return { authUser: user, token };
}

This is just me thinking out loud, not sure if this would work on your case and remove the infinite loop.

[roomman]

Thanks @mikkopaderes, I'm going to spend some time today digging into it a bit deeper. If you have time, it would be helpful to understand a bit more about your implementation.

In particular, I'd like to understand what is intended by setting up the onAuthStateChanged listener inside restore. My understanding (which is admittedly limited) is that, since Firebase 4.0.0, onAuthStateChanged triggers:

1. immediately after the listener is setup
2. when the user logs in
3. when the user logs out

Given authenticate and invalidate deal with logging in and out, I'm unsure what role onAuthStateChanged is playing. Please can you clarify your intent?

[roomman]

@mikkopaderes I think I've answered my own question here - I can see that auth.currentUser is null when restore is first called so I imagine you're setting up the listener to account for this?

[mikkopaderes]

Yes. It's indicated as well that this is the recommended way in their docs.

[roomman]

@mikkopaderes I've made a minimal reproduction here: https://github.com/roomman/bughunt-ember-auth-restore-loop

I've included notes in the README but, in summary, if you have two or more browser sessions open and authenticate in one the others try to restore and fail. On the second attempt, it succeeds but then the restore hook in the first session is fired, and then in the second, and so on. It's a never ending game of ping pong.

This is using your default authenticator, so I believe this affects all users of this repo.

In terms of the cause, the working hypothesis is that the user passed into onAuthStateChanged is subtly different each time. When it's resolved, ember-simple-auth triggers its sessionDataUpdated listener which re-calls authenticator.restore. That said, I've logged out the user objects and am struggling to find any differences between the sessions.

Any thoughts on what might be causing this?

[mikkopaderes]

I feel like that would only matter if the Authenticator was aware of changes to the auth user's token

It would be aware on every open of the web app. Otherwise by using data, you're just never going to synchronize again with Firebase Auth to see if the current user is still valid.

[roomman]

Does that mean Firebase itself is doing something under the hood, that ember-simple-auth is aware of?

I know Firebase will refresh the idToken every hour, but I'm unclear how ember-simple-auth knows about it. From the Firebase docs, it seems like you'd need to be triggering onIdTokenChanged instead of onAuthStateChanged. Or does Firebase automatically log a user out of Auth when the token expires or is revoked?

[roomman]

From the Firebase docs:

Prior to 4.0.0, [onAuthStateChanged] triggered the observer when users were signed in, signed out, or when the user's ID token changed in situations such as token expiry or password change. After 4.0.0, the observer is only triggered on sign-in or sign-out.

To keep the old behavior, see firebase.auth.Auth.onIdTokenChanged.

Based on the above and the current implementation of this addon, I'm trying to understand how ember-simple-auth is aware of when a session should be invalidated.

Slightly out of my comfort zone with all this, so I apologise if I'm not getting it 👍🏻

[mikkopaderes]

onAuthStateChanged will return a null user if the user has been disabled or deleted in Firebase Auth. For currently opened web apps, this won't sign out a user, but the next time the user refreshes the app or opens the app again, restore will get called and user returned by onAuthStateChanged will be null so end result is that the session would be invalidated and signed out.

[roomman]

Thanks for confirming. 👍🏻