Authentication and Authorization platform

[jirhiker]

we need to choose a new Auth platform. Fief is transforming and won't serve our needs as an auth platform in the future. However it will have a python SDK that should make working with the mature alternative platforms easier.

three alternatives are Clerk, Auth0, and Keycloak.

[jirhiker]

https://goauthentik.io/#comparison

[chasetmartin]

Some docs I've found interesting while reading about Clerk's user restriction offerings, inluding restricted access through enterprise SSO:
https://clerk.com/docs/authentication/configuration/restrictions#restricted

https://clerk.com/docs/authentication/enterprise-connections/overview

[jirhiker]

https://chatgpt.com/share/689a37ca-21f4-8013-8114-bfaefc536556

[jirhiker]

1. Casbin
   Type: Policy-based access control (supports ACL, RBAC, ABAC)
   Language/Runtime: Multiple (Go, Node.js, Java, Python, PHP, Rust…)
   Policy Storage: File (e.g., .conf, .csv), DB, or custom adapters

Strengths:

• Very flexible — can do RBAC, ABAC, MAC, DAC in the same engine.
• Rich ecosystem and adapters for various databases.
• Centralized policies; good for multi-service backends.

Weaknesses:

• Policy syntax is a learning curve.
• Evaluation speed can slow if policies are complex and large.
• More backend-oriented; not a drop-in for frontend apps.
• Best for: Complex systems needing flexible, centralized policy rules with multiple enforcement points.

2. CASL
   Type: Attribute-based access control (ABAC) & capability-based
   Language/Runtime: JavaScript/TypeScript (browser + Node.js)
   Policy Storage: Usually in memory or DB as JSON

Strengths:

• Very frontend-friendly — integrates well with React, Vue, Angular.
• Declarative, human-readable permission rules.
• Good for condition-based rules (can('read', 'Article', { published: true })).

Weaknesses:

• JS-only; not for polyglot backends.
• Large, dynamic policy sets can be slower in the browser.
• No built-in distributed policy storage or enforcement for microservices.
• Best for: Frontend UI enforcement and small-to-medium Node.js backends.

3. Cerbos
   Type: Policy-as-code engine (YAML, CEL expressions)
   Language/Runtime: Service (gRPC/HTTP API, written in Go)
   Policy Storage: YAML files (version-controlled) or GitOps

Strengths:

• Centralized policy decision point (PDP) for all services.
• Policies are versioned, testable, and CI/CD-friendly.
• Decouples business logic from authorization.
• Supports RBAC + ABAC with conditions.

Weaknesses:

• Requires running the Cerbos service alongside your apps.
• Adds network calls unless embedded.
• Less trivial for purely client-side enforcement.
• Best for: Microservices, multi-language stacks, where policy changes shouldn’t require code redeploy.

4. AccessControl.js
   Type: Role-based access control (RBAC) with grants
   Language/Runtime: JavaScript/TypeScript (Node.js)
   Policy Storage: In memory (JSON), can be persisted manually

Strengths:

• Simple API for CRUD-based permissions.
• Easy to define hierarchical roles.
• Good for quick RBAC needs in Node.js.

Weaknesses:

• No ABAC — purely role/resource/action-based.
• No native frontend integration.
• Not as feature-rich as CASL or Casbin for conditions.
• Best for: Small-to-medium Node.js backends that only need straightforward RBAC.

[jirhiker]

ADR: Choice of Identity Provider – Authentik over Keycloak and Clerk

Date: 2025-08-25
Status: Accepted
Context:

Our system requires an identity provider (IdP) to handle authentication, authorization, and user management across internal and external applications. We evaluated three options: Authentik, Keycloak, and Clerk. The IdP must support OIDC, SAML, flexible user/group management, modern admin UI, and self-hosting, while minimizing operational overhead.

Decision:

We selected Authentik as our identity provider.

Rationale:

Why not Keycloak?

• Mature and feature-rich, but has a complex architecture and higher operational burden (requires Java, WildFly, or Quarkus stack).
• The admin UI is dated and less intuitive compared to modern IdPs.
• Upgrades and configuration management are more difficult to automate.
• More overhead than we need for our scale.

Why not Clerk?

• Clerk provides a polished developer experience and easy integration.
• However, it is SaaS-only (no self-hosting) and locks us into a third-party vendor for authentication.
• Pricing can scale poorly for large numbers of users.
• Limited control over data residency and security posture, which is important for our use case.

Why Authentik?

• Fully open-source and actively maintained.
• Self-hosted: gives us control over data, configuration, and compliance.
• Modern architecture (Python, Django, PostgreSQL) – easier for our team to operate.
• Admin UI is intuitive, with first-class support for flows, policies, and extensibility.
• Built-in SAML and OIDC support, including role/group-based access control.
• Lower operational complexity than Keycloak while offering more flexibility and self-hosting control than Clerk.

Consequences:

• We will self-host Authentik, which requires us to operate and monitor the service.
• We retain full control over user data, compliance, and integrations.
• Some features may be less mature than Keycloak’s, but trade-offs are acceptable given reduced overhead and improved usability.
• Avoids vendor lock-in and unpredictable costs of SaaS identity providers.