Platform authorization

Last updated: Mar 2, 2026


Rationale

Authorization flows for Fluid Attacks' platform are performed by an in-house implementation. Such implementation currently supports:

  • Role permissions based on specific API resolvers.
  • Organization-level, group-level and user-level access for each role.

For example, if a user has the customer manager role for a given group, they can access these API resolvers for such a group. Similarly, the user can also access these API resolvers for organizations that are assigned to them.

The main reasons why we chose it over other alternatives are:

  • It allows us to keep a high access granularity thanks to its API revolver-based approach.
  • It has scaled well in terms of performance throughout the years.
  • It is legacy code inherited from the early days of the application.

Alternatives

As the application evolved, so did our interest in using a third-party authorization solution. Below are the ones we have reviewed, ordered from most to least interesting based on our specific needs.

Casbin

  • Casbin provides a Python library for authorization.
  • It does not provide any extra features outside of its main focus.
  • It is free as it is just a library, not a service.
  • SLA does not apply to it.
  • As it is just a library, authorization exists within the application backend, making authorization simpler and often faster. It inherits the scalability, security and redundancy of the application that hosts it.
  • As it is an open-source Python library, its engine is open source by inheritance.
  • It supports asynchronous environments.
  • As it is just a library, it does not need a Terraform provider.
  • It supports ACL, ABAC and RBAC, allowing us to handle even the most complex scenarios in our authorization model.
  • It uses the declarative PERM meta-model for declaring authorization models.
  • As it exists within the backend, it allows writing declarative unit tests and versioning them as code, heavily improving testability.
  • It supports real-time conditions for modeling complex scenarios like temporary access and quotas, among others.
  • It would force us to redefine our authorization model to fit its structure.

Permit.io

Okta FGA

  • Okta FGA provides a SaaS authorization platform based on OpenFGA.
  • Okta also provides a full authentication suite called Auth0.
  • Its pricing is not public.
  • It provides a >99% availability SLA.
  • It is a SaaS that automatically handles user databases, scaling, security, redundancy, and disaster recovery, among others.
  • In a sense, it is open source due to the fact that it implements OpenFGA over a SaaS model, but this could change over time.
  • Its Python library supports asynchronous environments.
  • It does not have a Terraform provider.
  • It supports ReBAC, allowing us to handle even the most complex scenarios in our authorization model.
  • It uses its own declarative configuration language.
  • It allows writing declarative unit tests and versioning them as code, heavily improving testability.
  • It supports real-time conditions for modeling complex scenarios like temporary access and quotas, among others.
  • It would force us to redefine our authorization model approach to fit its structure.

Oso

  • Oso provides a SaaS authorization platform.
  • It does not provide any extra features outside of its main focus.
  • It has a pricing model based on monthly active users (pay for what you use).
  • It provides a >99% availability SLA.
  • It is a SaaS service that automatically handles user databases, scaling, security, redundancy, and disaster recovery, among others.
  • Its authorization engine is currently not open source, but they are planning to release it.
  • Its Python library is not open source and seemingly does not support asynchronous environments, making it unusable for us.
  • It does not have a Terraform provider.
  • It supports ABAC and ReBAC, allowing us to handle even the most complex scenarios in our authorization model.
  • It uses its own declarative configuration language.
  • It allows writing declarative unit tests and versioning them as code, heavily improving testability.
  • It supports real-time conditions for modeling complex scenarios like temporary access and quotas, among others.
  • It would force us to redefine our authorization model to fit its structure.

Aserto

  • Aserto provides a SaaS authorization platform.
  • It does not provide any extra features outside of its main focus.
  • It has a pricing model based on monthly active users (pay for what you use).
  • It does not seem to provide an availability SLA.
  • Most of its architecture depends on external systems, forcing us to handle external user databases, scaling, and redundancy, among others.
  • Its authorization engine is open source.
  • Its Python library is open source and supports asynchronous environments.
  • It does not have a Terraform provider.
  • It supports ABAC, ReBAC and RBAC, allowing us to handle even the most complex scenarios in our authorization model.
  • It supports policies as code using Rego.
  • Although there is no documentation, it should allow writing declarative unit tests via Rego and versioning them as code, heavily improving testability.
  • It does not support real-time conditions for modeling complex scenarios like temporary access and quotas, among others.
  • It would force us to redefine our authorization model to fit its structure.

WorkOS

  • WorkOS provides SaaS solutions to requirements usually needed by enterprise applications.
  • Due to its broad focus, it provides services for user management, administrative portals, authentication, and authorization, among others.
  • Its pricing model makes it free for the first 10 million operations, but they don't tell how much extra operations cost.
  • It has a >99% availability SLA.
  • It is a SaaS service that automatically handles user databases, scaling, security, redundancy, and disaster recovery, among others.
  • Its authorization engine is not open source.
  • Its Python library supports asynchronous environments.
  • It does not have a Terraform provider.
  • It supports ABAC, ReBAC, and RBAC, allowing us to handle even the most complex scenarios in our authorization model.
  • It supports policies as code using its own proprietary syntax.
  • It does not support unit tests, highly affecting testability.
  • It does not support real-time conditions for modeling complex scenarios like temporary access and quotas, among others.
  • It would force us to redefine our authorization model to fit its structure.

Usage

We use an in-house implementation for all authorization flows at Fluid Attacks' platform.

Other in-house dependencies

On this page