A really great time-saving feature one can add to their Firebase application is allowing users to switch between multiple authenticated accounts. MotionLink 0.3.0 shipped with this feature Monday. In this post, I’ll be going through the high-level details of how one can implement this. What we want is a way for the user to sign into our application with one account. We then allow them to add more accounts such that, from their profile dropdown, they can see all the accounts they have added and can seamlessly switch into any of those accounts without having to go to the login screen again. Nice!
The first issue we run into stems from the fact that the Firebase client SDKs use a single-user auth model. This means there can only be one user signed into our application at any given time. When a user signs into the application with a different account, the old account that was signed in is signed out and replaced with the incoming account. One solution to this problem is to bypass the firebase SDK and call the Firebase Auth service directly via the REST API. This way we will be able to write a custom CurrentUser service, in our front end, that manages auth tokens and profiles for the multiple users that are signed into our app.
This will work. The problem, however, is the fact that we are bypassing the Firebase SDK which will cause us issues when calling the other Firebase services unless we decide to access all Firebase services via the REST API. Using the REST API for all services, however, will result in a lot of work on our side and a lot of code to maintain. This brings us to our second approach, custom auth with managed credentials.
The Firebase Admin SDK provides a function that accepts a user id, as input, and returns a JWT token as output. On the front end, this token can then be passed to the Firebase SDK to sign into that user account. Now, this is the foundation we need to enable account switching in our application. How? So get this:
We let a user sign into our application normally using their email/password or whatever sign-in method we have.
Once the user has signed in, we capture their user id, and maybe also their user name and profile picture, and save this to localStorage or Shared Preferences. We’ll call this storage, the keychain.
We then add another button to our application that allows the user to add another account. When they click this button, they will be taken through the whole sign-in process again, and if they sign into a different account, we add this account to the keychain as well.
Now we will extend our user profile dropdown to list all accounts in the keychain. When the user selects one of these accounts, we call our backend function with the target user id and get back a JWT token in return. We will then take this token and pass it to the Firebase client SDK.
Just like that, the currently signed-in user is now our target user. We have an application that allows users to switch accounts without having to log in again. Before we get too excited though, we cannot ship this.
With the system described above, all one needs to sign into the account of another user is the id of that target user. This is, of course, not secure. Imagine if all I needed to sign into your Google account is your email address. This is exactly what is happening here. Our backend function needs to request more credentials than just the user id. This is where the idea of managed credentials comes in.
By managed credential, I mean a credential that is not directly given by the user, but generated by the system. With this definition, a user id is also a managed credential which in this problem domain we can treat as a generated username. The username is unique to the user but is known by other users. We need to pair it with another managed credential not known by other users. We’ll simply call the second credential a token. When the user signs into their account a new token is generated for them and saved against their user id in the backend. This token is only valid for seven days or whatever is reasonable for our system. Now when we try to switch to a user account, the backend function will request the target user id and their token. If their token matches and is not expired the login succeeds, else we request the user goes back to the login page for that account. Now in our frontend keychain, we also store this token whenever the user signs into an account.
This is how the MotionLink console is implementing this functionality. The token, however, is not randomly generated, but computed from the user's GitHub token. The MotionLink console also encrypts the keychain. The keychain file is also treated in a volatile way. This means if it is corrupted, it is deleted and a new empty one is created.
I hope this article was helpful. Happy coding!
]]>
