back

by nateb2022·3mo ago·view on hn ↗
You're conflating authentication and authorization.

Clerk is an authentication provider for the most part, it concerns itself with telling you who the user is. Based on that your business logic should be able to determine what they are entitled to do.

They offer a Org/Role based RBAC but since you're doing something different I'd just scrap it entirely and roll your own authorization flow, they have a guide that'll help you get your own started here: https://clerk.com/docs/guides/secure/basic-rbac

1 comments
For the most part is the troubling part :D Ideally there is one vendor that handles this, as a team we don't want to deal with Clerk + something else just for RBAC, so naturally we tried to solve it via Clerk.

Their recommended guide is to pretty much have your own RBAC using key value pairs they offer, which is IMO relatively lazy and most teams come up with this on their own anyway. I wish they offered something that is not prone to someone editing a JSON input manually on their website. You can do basic stuff with it, build tooling around it, but again the fundamental model of only user having a role on the org level has its limitations.