- https://docs.wundergraph.com/docs/directives-reference/rbac-directive
- https://github.com/apollographql/router-biscuit-plugin
- https://dgraph.io/docs/graphql/security/graphtraversal-rules/
- https://www.osohq.com/post/graphql-authorization
- https://hasura.io/blog/the-complexity-of-building-a-graphql-api-permissions-layer-and-how-hasura-solves-this
- https://github.com/WenyXu/gqlgen_casbin_RBAC_example
- https://v1.casbin.org/docs/en/graphql-middlewares
- https://github.com/richmondgoh8/go-casbin
- https://github.com/mwasilew2/echo-gqlgen-casbin-rbac-example
- https://medium.com/@suni4596/rbac-guards-to-protect-golang-graphql-queries-and-mutations-74a1267c3289
- https://blog.logrocket.com/authorization-access-control-graphql/
Not related, but cool: https://wundergraph.com/blog/graphql_query_ast_minification
With Role-Based Access Control, we grant permissions based on roles, and then assign the roles to the users. For instance, WordPress has an administrator role with access to all resources, and the editor, author, contributor, and subscriber roles, which each restrict permissions in varying degrees, such as being able to create and publish a blog post, just create it, or just read it.
With Attribute-Based Access Control permissions are granted based on metadata that can be assigned to different entities, including users, assets, and environment conditions (such as the time of the day or the visitor’s IP address). For instance, in WordPress, the capability edit_others_posts is used to validate whether the user can edit other users’ posts.
In general terms, ABAC is preferable over RBAC because it allows us to configure permissions with fine-grained control, and the permission is unequivocal in its objective.
https://blog.logrocket.com/authorization-access-control-graphql/