4 ms·
I think the most important place to start is appreciating the distinction between authentication ("is the person trying to use my application really the person
by bjt 3y ago
I think the most important place to start is appreciating the distinction between authentication ("is the person trying to use my application really the person they say they are?", abbreviated "authn") and authorization ("is this person allowed to perform the action they're trying to perform?", abbreviated "authz").
Most of the comments on this page are referring to authentication. It's important to know, but also the piece you're likely to spend far less time on. It's where most of the heavy lifting will be done by some vendor or tool you set up instead of by your own code.
Authorization is far less likely to be something you get off the shelf and far more likely to be where you spend significant time. It can be very intimately connected to your business logic. Active Directory roles and groups are one authorization solution for a particular class of problems but I have only seen them used for controlling business internal assets (mostly file servers); not public-facing applications.
I really like Oso Academy as a resource for authorization topics. It's structured like a progressive course, though I don't know if they have the kind of exercises you mentioned.
https://www.osohq.com/academy https://www.osohq.com/academy
- hintymad 3y agoIt’s true that authZ requires a lot of customization. In my experience, though, authN is the harder one to implement when there is no existing infra to support it. How do we store and distribute credentials? How do we allow user-defined identities? How do we implement session keys? How do we scale out the authN layer? If we decide to use certs for authN, how do we manage certs lifecycle? The list is long.
- mooreds 3y ago> Authorization is far less likely to be something you get off the shelf and far more likely to be where you spend significant time Agreed. It is business logic, which means that it is harder to do off the shelf. That said, there are some startups trying to make this work. Here are the ones I'm aware of: * permit.io * cerbos.dev * osohq.com RBAC (role based access controls) can take you a long way for many applications, but at some point you will be more interested in ABAC (attribute based access control) or PBAC (policy based access control). If you want to dig in more, this is a nice overview: https://bok.idpro.org/article/id/42/ https://bok.idpro.org/article/id/42/
- buzziebee 3y agoJust to add another AuthZ approach to your great comment: ReBAC for Fine Grained Authorization (FGA) is also something that's becoming more common at the moment. Google released their Zanzibar whitepaper explaining how they implement FGA for things like YouTube and Drive and it's lead to a lot of new tooling based upon it. I'm working on a project at the moment with quite complex document management with various levels of access. Auth0 open sourced their FGA implementation recently as OpenFGA which looks ideal for our use case. As it's all fairly new there isn't much info out there about different ways of implementing it so we're kind of figuring it out as we go.
- tech_tuna 3y agoThis is the thing about "OAuth isn't about authentication" argument. . . there is quite a bit of overlap between RBAC and authorization. And that in itself, if quite confusing. What most annoys me is that OAuth is also very much about authentication, specifically outsourcing your authentication to a third party. It's not like OAuth has nothing to do with authentication, which is the knee jerk response you get from people when they attempt to simplify an explanation about what OAuth does and doesn't do.