Once you spend some time working with Firebase you definitely want to know how they do authentication, especially in terms of the auth tokens or session IDs. I have previously written about where or how the relevant auth tokens are stored for Web JavaScript SDK, but this article by Jacob Wenger does an excellent job of explaining all the different types of tokens that are involved across both the server-side and client-side SDKs.

Although you must go through the article yourself, primarily these are the four tokens that are involved or used:

• Custom Token – These have to be generated server-side with the Admin SDK. It is a JWT token with a maximum expiration of 1 hour from the time it is issued. The Firebase client SDKs use this token to authenticate themselves with the Firebase services.
• ID Tokens (or Access Tokens) – When the user logs into your web app via the client-side Firebase Auth SDK, the Firebase servers generate an ID or Access token which is a JWT with an expiration time of 1 hour since their creation or issued_at time. With every request sent by the client SDKs then, this token is used to authenticate the client by the Firebase services as well as any custom backends that you may have implemented.
• Refresh Tokens – These are OAuth 2.0 refresh tokens that are used by the client SDK to generate new ID/Access Tokens whenever they get expired after every 1 hour. This ensures the user of your app does not get logged out every 1 hour followed by a sign-in process again.
• Third-Party OAuth Access Tokens – Firebase supports a bunch of third-party identity providers (Github, Facebook, Google, Twitter, etc.) that themselves send along their own OAuth access tokens that can be used to authenticate their APIs. These tokens are not used to authenticate with Firebase services, may have varying expiry times and are not refreshed by Firebase when expired.