Platform authorization (in-house)

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.

Casbin was last reviewed on Jan 23, 2025.

Permit.io

Permit.io provides a SaaS authorization platform.
It also provides specialized authorization solutions for healthcare and third-party APIs .
It has a pricing model based on monthly active users (pay for what you use).
It does not seem to provide an availability SLA.
Although it supports a SaaS mode , they recommend handling infrastructure for production workloads.
Its authorization engine is open source.
Its Python library is open source and supports asynchronous environments .
It has a Terraform provider in beta phase.
It supports ABAC and ReBAC , allowing us to handle even the most complex scenarios in our authorization model.
Although its main focus is on allowing users to declare authorization models using a no-code approach, it also supports policies as code using Rego . Documentation on this matter could be improved.
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 was last reviewed on Jan 23, 2025.

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.

Okta FGA was last reviewed on Jan 23, 2025.

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.

Oso was last reviewed on Jan 23, 2025.

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.

Aserto was last reviewed on Jan 23, 2025.

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.

WorkOS was last reviewed on Jan 23, 2025.

Usage

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