Google auth can be out of sync with Firebase/Popcode auth state

The authentication method we’re using with the Google SDK maintains an internal global auth state, which is used to authenticate calls made with the Google client library. Currently there is no guarantee that the Google SDK’s auth state is consistent with Firebase or Popcode’s own state.

When logging in or out using Google OAuth, this generally will not be a problem; logging in authenticates us with the Google SDK, and we end the Google session when the user signs out. However, there are some other circumstances where they can get out of sync:

• Loading a Popcode environment when already logged in—Google maintains a session as well but it is likely to expire more quickly than Popcode’s own session
• Logging in using the deprecated Log In With GitHub method

As a corollary, we currently store the idToken from the Google auth response, with the intention of using it to authenticate future Google API calls. However, this token is not used for that purpose and there is no reason to store it. At a minimum, we should stop storing it, and modify business logic which assumes that the presence of an auth token is a requirement for a valid linked identity provider.

As for the overall problem, it’s currently neither here nor there because we don’t actually make any authenticated calls to a Google API. This will change with #1511 however.

I can see a number of potential solutions to the problem of keeping auth state in sync, and guaranteeing that a logged in user is able to make authenticated calls to the Google API using their linked Google credentials:

1. Ensure that a logged in Popcode user always has an active session in the Google auth SDK.

• This would mean logging the user out if a new tab is opened which has an active Popcode/Firebase session but no active Google auth session. This pattern is already used to keep Popcode and Firebase session state in sync.
• We would also need to either remove the GitHub login button entirely, or refuse to let people log in using GitHub to an account that is also linked to Google.
• In general this is not a terribly appealing option because it means we are locked in to always having the user log in with Google, and our session management is at the mercy of Google’s

2. Build in affordances for users initiating actions that they need further authentication in order to do. For instance if the user is logged in to Popcode with a Google-linked account, but does not actually have a Google session, and they tried to create an assignment in Classroom, we would show a Google auth dialog in order to create an active session in the Google auth SDK. For consistency, we would probably want to do the same thing with workflows that use the GitHub API.
3. Switch to the stateless authentication API in the Google SDK. This is a lower-level API that does not do any session management and just allows us to initiate an OAuth flow and get some tokens back.

• This would be a significant effort, though, because the auth token returned from authorize() is very short-lived. The higher-level API deals with periodically refreshing the token as long as a session is active, but as far as I can tell we would need to do this ourselves using the low-level API. Refreshing a token requires an API call that includes our private app secret, so we’d need to do it with server-side code; this would probably be reasonably straightforward using Firebase Cloud Functions but it would be our first time doing such a thing.
• The upside is that we could use getOfflineAccess() to get a long-lived refresh token, essentially putting us in the same situation as we are with GitHub where we are able to store an evergreen credential that we can use for API requests

Comienza revisando los flujos de autenticación descritos aquí, incluidos Google OAuth, la gestión de sesiones de Firebase/Popcode, el inicio de sesión de GitHub obsoleto y el trabajo planificado de Google API en #1511. No se nombran archivos ni pruebas, y el issue presenta varios diseños posibles; primero establece el enfoque de sincronización elegido y sus criterios de aceptación antes de localizar la implementación y las pruebas.