[sebmellen]

Kratos is not a complete Auth solution - if you self host you still need to write your own UI. We built another layer over it to handle RBAC and organization management. But at least Kratos covers all the complex crypto and security items related to authentication (not authorization, which I consider to be a part of “auth” writ large).

[mooreds]

Gotcha. There are still security concerns with the UI, but I agree, offloading the heavy lifting of password hashing, preventing enumeration attacks, and algorithm selection to a dedicated system makes sense.

Authorization is a whole other ball of wax. You can sometimes get by with RBAC, but it is far more often entangled with business logic. I've seen a set of new companies that offer outsourced authorization like permit.io and cerbos, and for an app of a certain complexity, think they are worth evaluating.

[akajla]

Building and maintaining UIs for RBAC and org management (including self-service, user-facing UIs) isn't trivial. That's why we built it into Warrant. We handle basic authz schemes like RBAC as well as fine-grained authz: https://blog.warrant.dev/introducing-the-self-service-dashbo...

[sebmellen]

We’ve found one of the biggest issue with RBAC services to be the integrations with our tech stack. Building the RBAC system ourselves helped it be congruent with our stack.

[mooreds]

That's cool. FusionAuth has a self service function: https://fusionauth.io/docs/v1/tech/account-management/ but it is limited to user profile data, rather than roles and permissions.

How do you prevent a user from assigning themselves roles they shouldn't? Is there some kind of cage preventing escalation?

[akajla]

The self-service dashboard is scoped only to privileged users (typically account/tenant-specific admins like IT admins) that have a specific permission.