Platform authorization

Last updated: Nov 4, 2026

Rationale

The Fluid Attacks platform uses an in-house implementation for its authorization flows. At this time, this implementation supports:

Role permissions for each API resolver
Organization-level, group-level, and user-level access for each role

For example, if a user has the customer manager role for a group, the user can access these API resolvers for that group. The user can also access these API resolvers for the organizations of the user.

Fluid Attacks selected it, and not other alternatives, because of these items:

It controls access for each API resolver. Thus, Fluid Attacks can keep very granular access.
Its performance stayed good while the application became larger.
It is legacy code from the first days of the application.

Alternatives

As the application changed, Fluid Attacks became more interested in a third-party authorization solution. These are the solutions that Fluid Attacks examined. The list starts with the solution that is most interesting for the requirements of Fluid Attacks.

Casbin

Casbin gives a Python library for authorization.
It does not give other features.
It is free, because it is only a library and not a service.
An SLA does not apply to it.
Because it is only a library, authorization is in the application backend. Thus, authorization is simpler and frequently faster. It gets the scalability, security, and redundancy of the application that hosts it.
Because it is an open-source Python library, its engine is also open source.
It supports asynchronous environments.
Because it is only a library, a Terraform provider is not necessary.
It supports ACL, ABAC, and RBAC. Thus, Fluid Attacks can manage the most complex access policies in its authorization model.
It uses the declarative PERM meta-model to declare authorization models.
Because it is in the backend, you can write declarative unit tests and keep versions of them as code. This makes testability much better.
It supports real-time conditions for complex access policies, for example, temporary access and quotas.
To use Casbin, Fluid Attacks must change its authorization model to agree with the Casbin structure.

Fluid Attacks last reviewed Casbin on Jan 23, 2025.

Permit.io

Permit.io gives a SaaS authorization platform.
It also gives special authorization solutions for healthcare and third-party APIs.
It has a pricing model based on monthly active users (you pay for what you use).
It does not seem to give an availability SLA.
It supports a SaaS mode, but Permit.io recommends that you manage the 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. Thus, Fluid Attacks can manage the most complex access policies in its authorization model.
Its primary purpose is to let users declare authorization models with a no-code approach. But it also supports policies as code with Rego. The documentation about policies as code can be better.
You can write declarative unit tests and keep versions of them as code. This makes testability much better.
It supports real-time conditions for complex access policies, for example, temporary access and quotas.
To use Permit.io, Fluid Attacks must change its authorization model to agree with the Permit.io structure.

Fluid Attacks last reviewed Permit.io on Jan 23, 2025.

Okta FGA

Okta FGA gives a SaaS authorization platform based on OpenFGA.
Okta also gives a full authentication suite, Auth0.
Its pricing is not public.
It gives a >99% availability SLA.
It is a SaaS that automatically manages user databases, scaling, security, redundancy, disaster recovery, and more.
It is partially open source, because it uses OpenFGA in a SaaS model. But this can change in the future.
Its Python library supports asynchronous environments.
It does not have a Terraform provider.
It supports ReBAC. Thus, Fluid Attacks can manage the most complex access policies in its authorization model.
It uses its own declarative configuration language.
You can write declarative unit tests and keep versions of them as code. This makes testability much better.
It supports real-time conditions for complex access policies, for example, temporary access and quotas.
To use Okta FGA, Fluid Attacks must change its authorization model to agree with the Okta FGA structure.

Fluid Attacks last reviewed Okta FGA on Jan 23, 2025.

Oso

Oso gives a SaaS authorization platform.
It does not give other features.
It has a pricing model based on monthly active users (you pay for what you use).
It gives a >99% availability SLA.
It is a SaaS service that automatically manages user databases, scaling, security, redundancy, disaster recovery, and more.
At this time, its authorization engine is not open source, but Oso plans to release it.
Its Python library is not open source, and it does not seem to support asynchronous environments. Thus, Fluid Attacks cannot use it.
It does not have a Terraform provider.
It supports ABAC and ReBAC. Thus, Fluid Attacks can manage the most complex access policies in its authorization model.
It uses its own declarative configuration language.
You can write declarative unit tests and keep versions of them as code. This makes testability much better.
It supports real-time conditions for complex access policies, for example, temporary access and quotas.
To use Oso, Fluid Attacks must change its authorization model to agree with the Oso structure.

Fluid Attacks last reviewed Oso on Jan 23, 2025.

Aserto

Aserto gives a SaaS authorization platform.
It does not give other features.
It has a pricing model based on monthly active users (you pay for what you use).
It does not seem to give an availability SLA.
Most of its architecture depends on external systems. Thus, Fluid Attacks would have to manage external user databases, scaling, redundancy, and more.
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. Thus, Fluid Attacks can manage the most complex access policies in its authorization model.
It supports policies as code with Rego.
There is no documentation, but it can possibly let you write declarative unit tests with Rego and keep versions of them as code. This would make testability much better.
It does not support real-time conditions for complex access policies, for example, temporary access and quotas.
To use Aserto, Fluid Attacks must change its authorization model to agree with the Aserto structure.

Fluid Attacks last reviewed Aserto on Jan 23, 2025.

WorkOS

WorkOS gives SaaS solutions for requirements that enterprise applications usually have.
Because it has a wide scope, it gives services for user management, administrative portals, authentication, authorization, and more.
With its pricing model, the first 10 million operations are free. But WorkOS does not tell the cost of more operations.
It has a >99% availability SLA.
It is a SaaS service that automatically manages user databases, scaling, security, redundancy, disaster recovery, and more.
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. Thus, Fluid Attacks can manage the most complex access policies in its authorization model.
It supports policies as code with its own proprietary syntax.
It does not support unit tests. This has a very bad effect on testability.
It does not support real-time conditions for complex access policies, for example, temporary access and quotas.
To use WorkOS, Fluid Attacks must change its authorization model to agree with the WorkOS structure.

Fluid Attacks last reviewed WorkOS on Jan 23, 2025.

Usage

Fluid Attacks uses an in-house implementation for all authorization flows in the Fluid Attacks platform.