Question posted in
The official documentation can be found here.

Redis – Should I cache Firebase idTokens for a while, after I authenticated it in node admin sdk?

I am building an app, where I need to use my own backend besides Firebase. I need to authenticate a logged-in user in my backend too. So I found this tutorial which does this. I send an idToken and verify this header in admin sdk in my node, based on the docs. I thought I could cache this token with redis or just a js map after the first verification for 10 minutes or as much as a user session would take, to speed things up, instead of verifying each request in a 10 min sess. I could probably cache the token in the phone too for some time?

My question is, what security consequences would this bring? Thank you.

To clarify I am not using custom tokens, I will be using the built in Firebase Authentication.

Tags:

2

Answers


  1. 0

    Some of the Firebase backend services keep a small cache of recent ID tokens, and their decoded results. So if they receive the exact same token, they’ll use the already decoded result. This is a riskless operation, as the decoding operation is idempotent: the same input will always deliver the same output.

    Login or Signup to reply.
  2. 0

    The convention is to send the ID token to your backend with every request. It’s not expensive to verify the token with the Admin SDK as shown in that documentation. It doesn’t cost any money.

    Typically what you’re supposed to do is use a listener to detect when the ID token changes (it will be refreshed automatically every hour), and keep using that token until the SDK delivers a new one to your callback. In web clients, you’re supposed to use onIdTokenChanged to register a callback to get changes to this token over time. There is no need to persist or cache this token – simply use whatever the callback most recently provided.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search