CODEWITHSUNDEEP
firebasegoogle-cloud-firestorefirebase-authentication
rID133
rID133

Reputation: 163

Best practice for Firebase authorization persistence and API calls

I've been following a tutorial to build a full stack website using firebase, react and redux. Log in sends a call to a back end function which uses firebase.auth().signInWithEmailAndPassword for logging in. The IdToken is passed back to the client and stored in localstorage. Authentication and state persistence then relies on the client checking if the current date is past the expiry of the JWT token. API calls to the back end cloud functions also require an Authorization header using 'Bearer {IdToken}'.

This structure is causing me lots of headaches. I've done lots of reading and my current understanding is that firebase has it's own authorization persistence (?) that I can implement directly on my front end. Then using a listener I can automatically get new Id tokens on auth state change. This would solve my problem of the tokens expiring every hour. From what I've read local storage of the tokens is also a security risk.

I'm unsure as to how that affects authorization of my function calls. Should I still use the authorization header or is there a more elegant firebase way of doing that?

Upvotes: 0

Views: 446

Answers (1)

Frank van Puffelen
Frank van Puffelen

Reputation: 600061

If you use Firebase Authentication's built-in providers, they indeed automatically persist the sign-in information information on most clients, restore it upon restart, and refresh the ID token just before it expires.

So if you use one of the standard providers, you can just get the user's ID token and then pass that to your Cloud Function.

You can even skip that step by using Callable Cloud Functions. For those, the Firebase Functions SDK passes the ID token along automatically, and the server automatically decodes and verifies it, and passes it to your code as context.auth.

Upvotes: 2

Related Questions