I agree, there are trade offs to both sides and we've been contemplating our strategy with a new site we're building. Having instant reaction when permissions have changed is attractive but querying the user's authority to do something every request is definitely a huge overhead with very little benefit, since 99.9% of the time your data is the same as the last query.
Storing this info in the JWT is also an idea but as many have pointed out starts to really cause issues with scale, and it just feels wrong.
We're using Firebase with an Angular front end for our upcoming project. One approach we are considering is to store the roles and resulting permissions in a database document representing the user's profile. When the user logs in we will read that with an Observable. All routing and UI will be based on the access granted to the user. Because it's an Observable we never have to requery it on a regular basis. If the data were to change the Observable would instantly be notified and obtain the latest revision, cascading through the UI.
Since the back end never trusts the data from the client we have to verify the user actions anyway. Data access will be handled with Firestore rules which verify authentication and match against the permissions stored in the user's profile/permissions document. Any Function API would do the same. Functions are stateless so there's no ability to cache and we are forced to check per request anyway.
We haven't built this out fully in production but that's our initial architecture. Should see how it works out in the next week or so.
I'd love to know how this works by when you have it ready. Some time ago I did an Angular + Firebase app with a similar structure. But, we store user roles inside the Firebase generated token using auth sdk in functions, there was a db node (realtime database, not firestore) which the client app was listening for changes in order to know when to fetch a new token and update it's roles.
That way, db access rules could be written using the 'auth' object... But things didn't end up very good as we expected it. The function in charge of assigning the recently created user sometimes took very long to do it's work (related to the function's cold start).
Any way, your architecture seems to be promising. Let me know how it ends!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree, there are trade offs to both sides and we've been contemplating our strategy with a new site we're building. Having instant reaction when permissions have changed is attractive but querying the user's authority to do something every request is definitely a huge overhead with very little benefit, since 99.9% of the time your data is the same as the last query.
Storing this info in the JWT is also an idea but as many have pointed out starts to really cause issues with scale, and it just feels wrong.
We're using Firebase with an Angular front end for our upcoming project. One approach we are considering is to store the roles and resulting permissions in a database document representing the user's profile. When the user logs in we will read that with an Observable. All routing and UI will be based on the access granted to the user. Because it's an Observable we never have to requery it on a regular basis. If the data were to change the Observable would instantly be notified and obtain the latest revision, cascading through the UI.
Since the back end never trusts the data from the client we have to verify the user actions anyway. Data access will be handled with Firestore rules which verify authentication and match against the permissions stored in the user's profile/permissions document. Any Function API would do the same. Functions are stateless so there's no ability to cache and we are forced to check per request anyway.
We haven't built this out fully in production but that's our initial architecture. Should see how it works out in the next week or so.
I'd love to know how this works by when you have it ready. Some time ago I did an Angular + Firebase app with a similar structure. But, we store user roles inside the Firebase generated token using auth sdk in functions, there was a db node (realtime database, not firestore) which the client app was listening for changes in order to know when to fetch a new token and update it's roles.
That way, db access rules could be written using the 'auth' object... But things didn't end up very good as we expected it. The function in charge of assigning the recently created user sometimes took very long to do it's work (related to the function's cold start).
Any way, your architecture seems to be promising. Let me know how it ends!