Replies: 1 comment
-
At the moment - we recommend proxying any FGA calls the frontend makes through your backend (you don't want one user to be able to know what another user has permissions for). Long term, we do have some plans to support client ids with more restricted permissions, as well as support for permissions based on tokens issued by a trusted provider. E.g. Your IDP can issue a token to the Frontend which can be used for Auth0 FGA but with a more limited set of permissions (e.g. the user can only be the user in the token). Some notes about FGA on the frontend, it would be a good idea to have a lot of relations, one for each action a user can take:
etc.. Also, as the number of relations grows, it might be a good idea to rethink the UX to support that. E.g. you know a user can view all resources listed (backend has already checked before returning them), but for each additional action, they can be lazy checked. When you navigate to a folder, you check what a user can do in that folder first, but then lazy load permissions for resources in that folder on click or on hover or maybe in parallel in the background. |
Beta Was this translation helpful? Give feedback.
-
OpenFGA is setup on my backend, and I'm currently trying to figure out the best way to integrate it with my SPA. Backend will always be the decision maker, but the frontend sometimes needs to be aware of certain permissions to view/hide certain pages/actions. Do you have any guidelines or examples around this?
Beta Was this translation helpful? Give feedback.
All reactions