6 ms·

It doesn't suck, it's literally bare-minimum what you need in order to securely retrieve the token. It's by far not THE worst, you're spouting total nonsense.

by zmxz 3y ago

It doesn't suck, it's literally bare-minimum what you need in order to securely retrieve the token. It's by far not THE worst, you're spouting total nonsense. What's THE worst is lack of attention, and one needs quite literally 10 minutes to read the RFC and understand it's fairly simple protocol with minimal number of parameters. I'm sorry you had a hard time with OAuth, but have you ever thought the problem is in you and not the protocol? Reason I'm asking is because you declare it sucks but you are not providing any kind of alternative of how it would not suck.

hyperpape 3y ago
> and one needs quite literally 10 minutes to read the RFC rfc 6749 is 4259 words according to wc -l. You mean that it takes 10 minutes to carelessly skim it. Never mind that there are several other OAuth RFCs.
- zmxz 3y ago
  You need 10 minutes of focused reading to understand what the purpose of the protocol is and you don't need all of the OAuth RFCs to implement the bare-minimum nor do you have to support all the grants available. Most people I worked with don't understand the purpose of OAuth and that's what the 10 minutes should be invested into. Or, you can, you know - nitpick and live in the world of gloom and doom where everything sucks.
  - haswell 3y ago
    For what it’s worth, I taught a series of classes/labs intended to help developers within my former employer’s ecosystem understand OAuth. What I learned after delivering the content to hundreds of devs over the years: OAuth confuses people, and for completely understandable reasons. Most people think about auth in terms of usernames/passwords or API keys. The mental models associated with these do not transfer to OAuth, and there are enough moving parts with client and server-side interactions that someone not already steeped in the authn/authz space will have some catching up to do. Forming an understanding of the basic concepts rarely happens in 10 minutes, and if that’s your experience, good on you. Most of us bang our head against the wall for a bit and some of us go on to teach classes about it. Bottom line: OAuth is hard. That is not the same thing as the general concept being simple.
    - dwaite 3y ago
      > Most people think about auth in terms of usernames/passwords or API keys. OAuth is hard to explain here because it is not an authentication protocol, and without extensions has severe security flaws in being one. OpenID Connect is the most popular effort extending OAuth to also handle authentication. But that doesn't change that the thing OAuth is most associated with is not what it actually sets out to accomplish.
      - haswell 3y ago
        Yeah, this misconception is at the heart of so much confusion, and far too many OAuth implementations were clearly borne of "well, the customer was demanding we support OAuth so we implemented it", and there was clearly no understanding of the distinction between authn and authz, or what use cases are actually getting solved. I once worked with a vendor who provided an API and required all API clients to use OAuth with Auth Code Grant Flow. The API was designed to support backend automation use cases within the product, and could execute functionality behind the scenes headlessly. Auth Code Grant Flow requires interactive login by a user sitting at a keyboard, and they never stopped to consider that backend automation use cases are not going to work well if someone has to periodically execute an interactive auth flow. This wasn't a once-in-a-year occurrence since they enforced relatively short refresh token timeouts. The degree of confusion and the prevalence of that confusion on this subject is quite high. Someone gets a task to "Implement OAuth", and they see that Auth Code Grant Flow is the most common, so that must be what we should implement.
    - zmxz 3y ago
      > Forming an understanding of the basic concepts rarely happens in 10 minutes It happens when you're working and have sufficient experience, knowledge and practice when it comes to web, programming and HTTP. It's impractical, irresponsible and insane to have anyone other than a person with sufficient knowledge to work on application / API that supports OAuth and for person with proper expertise - the protocol is simple because it's literally the bare minimum needed to establish secure request/response pattern. I work with SAML 2.0 and OAuth2/OIDC, I deal with programmers and other people within areas of API, authentication, authorization and it is true that majority of people I interacted with are having troubles understanding these protocols. However, what I can attest to is that they're also extremely underwhelming as people working in IT, with bad work habits and misplaced focus. It's impossible to explain or clear up the protocol to such audience because they lack much more when it comes to knowledge and discipline. But, I did interact with several brilliant people with far less experience compared to me who did get the purpose of this protocol and who implemented it successfully and have done so quite fast. What the wall of text means is that where there's will - there's a way. You can't force knowledge into audience who can't or refuse to understand it, so there's no point in even trying to do it let alone draw conclusions how the protocol is hard, confusing or difficult when there's whole knowledge void in other pre-requisite areas.

by zmxz 3y ago

hyperpape 3y ago

> and one needs quite literally 10 minutes to read the RFC rfc 6749 is 4259 words according to wc -l. You mean that it takes 10 minutes to carelessly skim it. Never mind that there are several other OAuth RFCs.

zmxz 3y ago
You need 10 minutes of focused reading to understand what the purpose of the protocol is and you don't need all of the OAuth RFCs to implement the bare-minimum nor do you have to support all the grants available. Most people I worked with don't understand the purpose of OAuth and that's what the 10 minutes should be invested into. Or, you can, you know - nitpick and live in the world of gloom and doom where everything sucks.
- haswell 3y ago
  For what it’s worth, I taught a series of classes/labs intended to help developers within my former employer’s ecosystem understand OAuth. What I learned after delivering the content to hundreds of devs over the years: OAuth confuses people, and for completely understandable reasons. Most people think about auth in terms of usernames/passwords or API keys. The mental models associated with these do not transfer to OAuth, and there are enough moving parts with client and server-side interactions that someone not already steeped in the authn/authz space will have some catching up to do. Forming an understanding of the basic concepts rarely happens in 10 minutes, and if that’s your experience, good on you. Most of us bang our head against the wall for a bit and some of us go on to teach classes about it. Bottom line: OAuth is hard. That is not the same thing as the general concept being simple.
  - dwaite 3y ago
    > Most people think about auth in terms of usernames/passwords or API keys. OAuth is hard to explain here because it is not an authentication protocol, and without extensions has severe security flaws in being one. OpenID Connect is the most popular effort extending OAuth to also handle authentication. But that doesn't change that the thing OAuth is most associated with is not what it actually sets out to accomplish.
    - haswell 3y ago
      Yeah, this misconception is at the heart of so much confusion, and far too many OAuth implementations were clearly borne of "well, the customer was demanding we support OAuth so we implemented it", and there was clearly no understanding of the distinction between authn and authz, or what use cases are actually getting solved. I once worked with a vendor who provided an API and required all API clients to use OAuth with Auth Code Grant Flow. The API was designed to support backend automation use cases within the product, and could execute functionality behind the scenes headlessly. Auth Code Grant Flow requires interactive login by a user sitting at a keyboard, and they never stopped to consider that backend automation use cases are not going to work well if someone has to periodically execute an interactive auth flow. This wasn't a once-in-a-year occurrence since they enforced relatively short refresh token timeouts. The degree of confusion and the prevalence of that confusion on this subject is quite high. Someone gets a task to "Implement OAuth", and they see that Auth Code Grant Flow is the most common, so that must be what we should implement.
  - zmxz 3y ago
    > Forming an understanding of the basic concepts rarely happens in 10 minutes It happens when you're working and have sufficient experience, knowledge and practice when it comes to web, programming and HTTP. It's impractical, irresponsible and insane to have anyone other than a person with sufficient knowledge to work on application / API that supports OAuth and for person with proper expertise - the protocol is simple because it's literally the bare minimum needed to establish secure request/response pattern. I work with SAML 2.0 and OAuth2/OIDC, I deal with programmers and other people within areas of API, authentication, authorization and it is true that majority of people I interacted with are having troubles understanding these protocols. However, what I can attest to is that they're also extremely underwhelming as people working in IT, with bad work habits and misplaced focus. It's impossible to explain or clear up the protocol to such audience because they lack much more when it comes to knowledge and discipline. But, I did interact with several brilliant people with far less experience compared to me who did get the purpose of this protocol and who implemented it successfully and have done so quite fast. What the wall of text means is that where there's will - there's a way. You can't force knowledge into audience who can't or refuse to understand it, so there's no point in even trying to do it let alone draw conclusions how the protocol is hard, confusing or difficult when there's whole knowledge void in other pre-requisite areas.