Is your feature request related to a problem? Please describe.
I'm using Firebase auth with a SPA and my own backend services. My backend is a series of serverless functions hosted on a provider other than Firebase/GCP.
Currently, when the auth FirebaseTokenVerifier fetches the Firebase public keys, it caches them just by storing them in-memory in the JS process by setting them on the current FirebaseTokenVerifier object (see
|
private fetchPublicKeys(): Promise<{[key: string]: string}> { |
).
However, since I'm running my server code as a bunch of serverless functions rather than a persistent server process, this means that I will never have cached public keys (or at least, I need to assume I never will). For my specific use case, the latency hit of making that HTTP request on every single server API request is unacceptable; I need a way to properly cache the result of that public key HTTP request across my various serverless function request instances.
Describe the solution you'd like
I'd like some way to specify either my own caching strategy or my own fetching function for getting and storing Google public keys. I have no strong thoughts on what this should look like, given the code is all currently private to the module.
One potential solution: make FirebaseTokenVerifier.publicKeys and FirebaseTokenVerifier.publicKeysExpireAt public, so I could manually manage making the HTTP requests myself and then just inject the final results into the existing flow / FirebaseTokenVerifier object. I don't think this would require any other framework changes.
Describe alternatives you've considered
My current plan of action is to avoid using this library entirely and manage the entire JWT verification process using a third-party library. I appreciate that https://firebase.google.com/docs/auth/admin/verify-id-tokens#web includes clear instructions to do so, but this seems like a shame given I'm using a language (JS) you officially support.
Alternatively, if I understand JWTs correctly, I can theoretically manage this at the application layer by caching the token itself: verify it once, store it in a cache (I have a Redis instance already), and future requests can compare the newly-received token against that known-validated token instead of validating every request. This seems unnecessarily complex, and risks user implementation error.
Is your feature request related to a problem? Please describe.
I'm using Firebase auth with a SPA and my own backend services. My backend is a series of serverless functions hosted on a provider other than Firebase/GCP.
Currently, when the auth FirebaseTokenVerifier fetches the Firebase public keys, it caches them just by storing them in-memory in the JS process by setting them on the current FirebaseTokenVerifier object (see
firebase-admin-node/src/auth/token-verifier.ts
Line 287 in 01d8177
However, since I'm running my server code as a bunch of serverless functions rather than a persistent server process, this means that I will never have cached public keys (or at least, I need to assume I never will). For my specific use case, the latency hit of making that HTTP request on every single server API request is unacceptable; I need a way to properly cache the result of that public key HTTP request across my various serverless function request instances.
Describe the solution you'd like
I'd like some way to specify either my own caching strategy or my own fetching function for getting and storing Google public keys. I have no strong thoughts on what this should look like, given the code is all currently private to the module.
One potential solution: make FirebaseTokenVerifier.publicKeys and FirebaseTokenVerifier.publicKeysExpireAt public, so I could manually manage making the HTTP requests myself and then just inject the final results into the existing flow / FirebaseTokenVerifier object. I don't think this would require any other framework changes.
Describe alternatives you've considered
My current plan of action is to avoid using this library entirely and manage the entire JWT verification process using a third-party library. I appreciate that https://firebase.google.com/docs/auth/admin/verify-id-tokens#web includes clear instructions to do so, but this seems like a shame given I'm using a language (JS) you officially support.
Alternatively, if I understand JWTs correctly, I can theoretically manage this at the application layer by caching the token itself: verify it once, store it in a cache (I have a Redis instance already), and future requests can compare the newly-received token against that known-validated token instead of validating every request. This seems unnecessarily complex, and risks user implementation error.