61–70 of 93 posts
I'm also interested in this, but specifically something that covers authentication between services and in particular situations where a user authenticates against service a and now service a needs to ask service b to do something on behalf of the user. Not just a handwavy "use OAuth" but more concrete and thorough.
Huh, I always forget a lot of programmers weren't around when this stuff was invented. It's all actually pretty simple, and very little complexity. However, there are so many "gotchas" (that can result in zero security) that anyone writing a guide like this would probably have you sign a waiver, then any company you work for sign a waiver, and include your firstborn child. For example, user/pass is pretty simple on t…
Actually, I think we're doing a huge disservice to our profession as programmers when we call stuff like this "an insane number of gotchas". This is no critique of you or your post specifically, mind you, and I know where you're coming from. But it's a critique of a general tendency among programmers to call anything that requires a bit of knowledge and thought beyond the simplest surface level solution "complex" or…
Huh, I always forget a lot of programmers weren't around when this stuff was invented. It's all actually pretty simple, and very little complexity. However, there are so many "gotchas" (that can result in zero security) that anyone writing a guide like this would probably have you sign a waiver, then any company you work for sign a waiver, and include your firstborn child. For example, user/pass is pretty simple on t…
Also... don't rely on slow hashes themselves for rate limiting. They're slow because they eat up CPU. Rate limit the requests themselves or you're setting yourself up for denial of service fun. (And also, slow for your server does not necessarily mean prohibitively slow for an attacker's cluster if they do manage to dump your DB. Salting is useful and hopefully uniquely done per account for you by your hashing function, but it's also useful to just forbid very weak passwords entirely, and maybe go so far as to forbid even strong-looking ones that have shown up in data leaks.)
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.
Earlier quoted context omitted.
Actually, I think we're doing a huge disservice to our profession as programmers when we call stuff like this "an insane number of gotchas". This is no critique of you or your post specifically, mind you, and I know where you're coming from. But it's a critique of a general tendency among programmers to call anything that requires a bit of knowledge and thought beyond the simplest surface level solution "complex" or…
IMO it is insane to implement Auth on your own in almost all real life use cases. You wouldn't roll your own crypto either. Good for learning but for real users use something that is tried and tested.
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 th…
Huh, I always forget a lot of programmers weren't around when this stuff was invented. It's all actually pretty simple, and very little complexity. However, there are so many "gotchas" (that can result in zero security) that anyone writing a guide like this would probably have you sign a waiver, then any company you work for sign a waiver, and include your firstborn child. For example, user/pass is pretty simple on t…
> slow hashes work great here Also... don't rely on slow hashes themselves for rate limiting. They're slow because they eat up CPU. Rate limit the requests themselves or you're setting yourself up for denial of service fun. (And also, slow for your server does not necessarily mean prohibitively slow for an attacker's cluster if they do manage to dump your DB. Salting is useful and hopefully uniquely done per account…
What made me understand these things the most, was setting this up just for myself. For example host your own instance of Zitadel, Authentik or whatever you find most appealing. Tinker a bit around with it. Then use that instance to authenticate yourself somewhere, i.e. another service where you can set up your own oauth provider. Take a look at the API requests, take a look the code of some OAuth implementation, for…
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 th…
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/
Earlier quoted context omitted.
As mentioned elsewhere, I'd probably start with OAuth2.1 (not quite a standard but well on its way) as this updates the OAuth2 standard, as well as consolidates lots of improvements. https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.htm...
OAuth 2.1 has no new features. It is OAuth 2.0 rolled up with all the specs since 2.0. It is the better place to start for learning about delegated authorization.
From the spec:
"This Standards Track specification consolidates the information in all of these documents and removes features that have been found to be insecure..."