4 ms·

> Apart from that, OAuth2 is such a vast area that we have been able to only answer the fundamental why questions and review the most popular delegation grants

> Apart from that, OAuth2 is such a vast area that we have been able to only answer the fundamental why questions and review the most popular delegation grants in this article. So, what we've learned is that OAuth2 is not a single thing, and that it is too complex.

lxgr 2y ago
That matches my experience, and it doesn't help that the RFCs, in trying to explain it, have declared defeat early on.
- mdhb 2y ago
  The oauth 2.1 spec does a lot to bring everything together and simplify things at the same time.
- chrysoprace 2y ago
  It's also hard to find the relevant RFC, because older RFCs contain grant types that are no longer recommended, but still widely in use. This means that if you're working on a legacy application that's using something like the implicit grant, to actually learn about it, you need to read superseded RFCs.
  - motorest 2y ago
    > It's also hard to find the relevant RFC, because older RFCs contain grant types that are no longer recommended, but still widely in use. Why do you think this is a problem? So old RFCs specify grant types. That's ok, that's the whole point of specifying authentication schemes. Some are not recommended? That's perfectly fine, it just means there are better, safer ways to implement a flow. Are they still widely use? That's great, you already know where they are specified. So what's the problem? > This means that if you're working on a legacy application that's using something like the implicit grant, to actually learn about it, you need to read superseded RFCs. I don't understand. Where do you see a problem? You said you know where a specific flow is specified, and you want to learn it. You even have a implementation? What's the problem? Does a "superseded" tag bother you?
7bit 2y ago
OAuth is authorization only. The part where it is vast is the different mechanics to grant/delegate access. And that's really needed because you need to be able to have Oauth working fo humans and machines where the accessing service can be the app on your phone, or some backend server.
motorest 2y ago
> So, what we've learned is that OAuth2 is not a single thing, and that it is too complex. OAuth specifies multiple authorization flows, each one including independent risk mitigation steps. In my opinion OAuth2 is not "too complex". It's a subject matter that has intrinsic complexity, but one which isn't that high to be blunt. Of course people who are oblivious to the subject and just glance at it from a distance might be tempted to dismiss it entirely as too complex. This is indeed a recurring problem in software development circles, where typically developers are too quick to criticize existing work because they don't understand requirements, are oblivious to the problem domain, and do not understand how the problems they don't understand are solved. But this doesn't mean the problem domain is complex or too complex. There is a reason why this sort of walkthrough is very useful: those who are oblivious to the subject and just glance at it from a distance have a way to walk through the requirements and the happy flow in a easy-to-digest way. Hence the comments that now OAuth2 is actually not that complex, it's the RFCs that specify it that are the problem.
- Salgat 2y ago
  OAuth's biggest issue is that unless you are regularly working with it, you'll probably forget most of the details once you're done implementing it. Similar story with regex for me, it's not that complex, but when I'm building queries a couple times a year at most, I end up forgetting it mostly. It's not surprising that most folks don't understand it, even if at one point they did in the past.
  - cruffle_duffle 2y ago
    There are one page regex cheat sheets you can print out and put in your workspace. Then you simply consult the cheat sheets. Unfortunately oauth cannot be compressed into a cheat sheet. But yeah, oauth is absolutely something you forget right after using it and have to bootstrap every time you touch it.
    - motorest 2y ago
      > Unfortunately oauth cannot be compressed into a cheat sheet. What's so hard about a specific authentication flow? You have a user, a client app, a resource service, and an authorization service. You have a sequence of requests that send data back and forth. The end result is a token that client apps can send to a resource service. What bit requires volumes to understand? Take a minute to check RFC6749. All authorization flows in there require between 2 to 6 pages to fully define. Is this too much info to parse? https://datatracker.ietf.org/doc/html/rfc6749 https://datatracker.ietf.org/doc/html/rfc6749

lxgr 2y ago

That matches my experience, and it doesn't help that the RFCs, in trying to explain it, have declared defeat early on.

mdhb 2y ago
The oauth 2.1 spec does a lot to bring everything together and simplify things at the same time.
chrysoprace 2y ago
It's also hard to find the relevant RFC, because older RFCs contain grant types that are no longer recommended, but still widely in use. This means that if you're working on a legacy application that's using something like the implicit grant, to actually learn about it, you need to read superseded RFCs.
- motorest 2y ago
  > It's also hard to find the relevant RFC, because older RFCs contain grant types that are no longer recommended, but still widely in use. Why do you think this is a problem? So old RFCs specify grant types. That's ok, that's the whole point of specifying authentication schemes. Some are not recommended? That's perfectly fine, it just means there are better, safer ways to implement a flow. Are they still widely use? That's great, you already know where they are specified. So what's the problem? > This means that if you're working on a legacy application that's using something like the implicit grant, to actually learn about it, you need to read superseded RFCs. I don't understand. Where do you see a problem? You said you know where a specific flow is specified, and you want to learn it. You even have a implementation? What's the problem? Does a "superseded" tag bother you?

7bit 2y ago

OAuth is authorization only. The part where it is vast is the different mechanics to grant/delegate access. And that's really needed because you need to be able to have Oauth working fo humans and machines where the accessing service can be the app on your phone, or some backend server.

motorest 2y ago

> So, what we've learned is that OAuth2 is not a single thing, and that it is too complex. OAuth specifies multiple authorization flows, each one including independent risk mitigation steps. In my opinion OAuth2 is not "too complex". It's a subject matter that has intrinsic complexity, but one which isn't that high to be blunt. Of course people who are oblivious to the subject and just glance at it from a distance might be tempted to dismiss it entirely as too complex. This is indeed a recurring problem in software development circles, where typically developers are too quick to criticize existing work because they don't understand requirements, are oblivious to the problem domain, and do not understand how the problems they don't understand are solved. But this doesn't mean the problem domain is complex or too complex. There is a reason why this sort of walkthrough is very useful: those who are oblivious to the subject and just glance at it from a distance have a way to walk through the requirements and the happy flow in a easy-to-digest way. Hence the comments that now OAuth2 is actually not that complex, it's the RFCs that specify it that are the problem.

Salgat 2y ago
OAuth's biggest issue is that unless you are regularly working with it, you'll probably forget most of the details once you're done implementing it. Similar story with regex for me, it's not that complex, but when I'm building queries a couple times a year at most, I end up forgetting it mostly. It's not surprising that most folks don't understand it, even if at one point they did in the past.
- cruffle_duffle 2y ago
  There are one page regex cheat sheets you can print out and put in your workspace. Then you simply consult the cheat sheets. Unfortunately oauth cannot be compressed into a cheat sheet. But yeah, oauth is absolutely something you forget right after using it and have to bootstrap every time you touch it.
  - motorest 2y ago
    > Unfortunately oauth cannot be compressed into a cheat sheet. What's so hard about a specific authentication flow? You have a user, a client app, a resource service, and an authorization service. You have a sequence of requests that send data back and forth. The end result is a token that client apps can send to a resource service. What bit requires volumes to understand? Take a minute to check RFC6749. All authorization flows in there require between 2 to 6 pages to fully define. Is this too much info to parse? https://datatracker.ietf.org/doc/html/rfc6749 https://datatracker.ietf.org/doc/html/rfc6749