5 ms·
Show HN: Open Source Authentication and Authorization
I’m Rishabh and the co-founder and CTO at https://supertokens.com https://supertokens.com (YC S20). We offer open-source user authentication and we just released our user roles product for companies implementing authorization.
Our users are web developers, and a prominent and adjacent pain point for our users is authorization. Developers typically implement two independent solutions for authentication and authorization. Offering AuthN and AuthZ in a single solution is something we’ve been thinking about for the last few years.
Quick primer, authentication is knowing who the user is, and authorization is knowing what the user has access to. A physical analogy: A person enters a building. Authentication means reading their ID card and knowing that the person’s name is John. Authorization means knowing which floors, offices, and files John has access to.
With increasing privacy and data complexity, companies like Netflix[1], Slack[2], and Airbnb[3] have built out their own complex authorization systems.
To build our user roles product, we started with a first principles approach of covering authorization use cases using scripting languages such as XACML and OPA. But looking at existing solutions built by talented teams like Oso[4], Aserto[5], Cerbos[6], Strya[7], we realized that while these were powerful solutions, they were often overkill for most early to mid-stage companies (especially on the B2C side).
We went back to the drawing board, reached out to our users and after dozens of conversations, we realized that most authorization needs require the ability to
1. Assign and manage roles and permissions
2. Store roles in the DB and session tokens to make it readable on the frontend and
3. Protect APIs and websites based on these roles and permissions.
And so, we built user roles – a simple RBAC authorization service that focuses on the balance between simplicity and utility. It doesn’t cover many complex cases and we’re not looking to displace any of the authorization incumbents. But you can add AuthN and AuthZ using a single solution, quickly.
In the near future, we’ll be launching an admin GUI where you can manage your users and their roles with a few clicks.
We’d love for you to try it out and hear what additional functionality you’d like to see. What are your favorite authentication providers and what do they get right?
- [1]: https://conferences.oreilly.com/velocity/vl-ca-2018/cdn.oreillystatic.com/en/assets/1/event/270/The%20distributed%20authorization%20system_%20A%20Netflix%20case%20study%20Presentation.pdf https://conferences.oreilly.com/velocity/vl-ca-2018/cdn.orei...
- [2]: https://slack.engineering/role-management-at-slack/ https://slack.engineering/role-management-at-slack/
- [3]: https://medium.com/airbnb-engineering/himeji-a-scalable-centralized-system-for-authorization-at-airbnb-341664924574 https://medium.com/airbnb-engineering/himeji-a-scalable-cent...
- [4]: https://www.osohq.com/ https://www.osohq.com/
- [5]: https://www.aserto.com/ https://www.aserto.com/
- [6]: https://cerbos.dev/ https://cerbos.dev/
- [7]: https://www.styra.com/ https://www.styra.com/
- 0xbadcafebee 4y agoStupid question: judging by your feature comparison, the only thing you have over Keycloak is you provide managed instances. So why not just be a Keycloak managed provider? They also seem to have features you lack?
- grepfru_it 4y agoAuthelia is the giant open source elephant in this room
- windexh8er 4y agoThat it is, but is a bit convoluted. I ended up settling on Authentik. [0] [0] https://goauthentik.io/ https://goauthentik.io/
- rishabhpoddar 4y agoThere are other differences too: - Our architecture is different: We provide a frontend SDK with react components that are embedded in your own website - giving you more control and a better dev experience. The frontend doesn't talk to SuperTokens directly, but instead proxies requests via your backend API layer (using our backend SDK). This makes it much easier for you to customise the backend auth logic (you can reuse your API code and also are not forced to use Java), and also enables us to handle your app's session management out of the box. - For use cases that don't need OAuth (for example if you have a single website), we don't require you to use the protocol. This makes it simpler to setup auth, especially for people not familiar with OAuth and its various flows already. - There are other feature differences - some features that we have that they don't and vice versa. But this is just a function of time investment on either side.
- ryhotsi 4y ago[dead]
- deleted 4y ago[deleted]