4 ms·

Correction, OAuth < 2.0 sucks. OAuth2.0 is actually easy to use and more secure.

by dpres 15y ago

peterbraden 15y ago
nope, oAuth 2 is still a pain to use. all of the oAuths are developer hostile, they make authentication a many step process with many potential fail cases.
- alexbilbie 15y ago
  OAuth 2 a simple two step process: 1) Redirect the user 2) Do a POST request to acquire an access token How is that a pain?
  - pjscott 15y ago
    And to be pedantic, there's a third step: 3) When you make an authenticated API call, send the access token along with the request, and make sure you're using HTTPS. The HTTPS part is important to give a bunch of the security guarantees than OAuth 1 gives you with plain HTTP and some complicated crypto dancing around.
    - andrewmccall 15y ago
      The problem with OAuth1 was that the complicated crypto dancing around was exactly that, complicated. Making sure you're using HTTPS is hardly a big ask for developers on either the client or the server and frankly is probably a much better idea given most of these services are more likely than not sending some form of private data.
tomjen3 15y ago
There is no reason to use OAuth ever, in any shape, under any circumstance, which is a bad for the tech but (in this case) good for everybody else. Instead of using the bloated OAuth multiple requests back and forth, permission keys, auth keys, consumer secrects, etc, etc. you can simply add an additional header saying "client id" which the service provider can then use to "secure" his er her service as he sees fit. OAuth is a bloated attempt to paper around the simple solution so that the astronaut architects who made it can feel smug about themselves. OAuth solves no problems, helps nobody and has (drastically) polluted our ecosystem. To hell with that shit.
- icebraining 15y ago
  Can you explain how would that work?
- ryanpetrich 15y ago
  > you can simply add an additional header saying "client id" which the service provider can then use to "secure" his er her service as he sees fit. OAuth 2.0 is basically that + a standardized protocol for requesting a "client id", which is why it's completely insecure over standard HTTP.
  - dpres 15y ago
    Thats why OAuth2.0 protocol is limited to HTTPS and is said to never be implemented over HTTP.
- andrewmccall 15y ago
  Except the client id has to be generated so that you know which client was authorised with it - in the case of something like Facebook or twitter, so you can revoke their access. That means you have to agree on a way of exchanging that client ID. Which at it's simplest is what OAuth 2 does with bearer tokens. If you have no use for the other parts of the spec then just ignore them, it's all optional and you only need to implement it if you need it.
- dpres 15y ago
  Sounds like your saying, "Don't use OAuth because it's bloated, create your own API auth protocol and make everyone use that non-standard protocol for my API". That forces developers to implement "custom" protocols per API that may actually be worse than OAuth. You must not be developer. OAuth 2.0 is not bloated and pretty much 2 steps with a clause to never use it via HTTP. How could it be more simple?

Correction, OAuth < 2.0 sucks. OAuth2.0 is actually easy to use and more secure.

by dpres 15y ago

Correction, OAuth < 2.0 sucks. OAuth2.0 is actually easy to use and more secure.

nope, oAuth 2 is still a pain to use. all of the oAuths are developer hostile, they make authentication a many step process with many potential fail cases.

alexbilbie 15y ago
OAuth 2 a simple two step process: 1) Redirect the user 2) Do a POST request to acquire an access token How is that a pain?
- pjscott 15y ago
  And to be pedantic, there's a third step: 3) When you make an authenticated API call, send the access token along with the request, and make sure you're using HTTPS. The HTTPS part is important to give a bunch of the security guarantees than OAuth 1 gives you with plain HTTP and some complicated crypto dancing around.
  - andrewmccall 15y ago
    The problem with OAuth1 was that the complicated crypto dancing around was exactly that, complicated. Making sure you're using HTTPS is hardly a big ask for developers on either the client or the server and frankly is probably a much better idea given most of these services are more likely than not sending some form of private data.

tomjen3 15y ago

There is no reason to use OAuth ever, in any shape, under any circumstance, which is a bad for the tech but (in this case) good for everybody else. Instead of using the bloated OAuth multiple requests back and forth, permission keys, auth keys, consumer secrects, etc, etc. you can simply add an additional header saying "client id" which the service provider can then use to "secure" his er her service as he sees fit. OAuth is a bloated attempt to paper around the simple solution so that the astronaut architects who made it can feel smug about themselves. OAuth solves no problems, helps nobody and has (drastically) polluted our ecosystem. To hell with that shit.

icebraining 15y ago
Can you explain how would that work?
ryanpetrich 15y ago
> you can simply add an additional header saying "client id" which the service provider can then use to "secure" his er her service as he sees fit. OAuth 2.0 is basically that + a standardized protocol for requesting a "client id", which is why it's completely insecure over standard HTTP.
- dpres 15y ago
  Thats why OAuth2.0 protocol is limited to HTTPS and is said to never be implemented over HTTP.
andrewmccall 15y ago
Except the client id has to be generated so that you know which client was authorised with it - in the case of something like Facebook or twitter, so you can revoke their access. That means you have to agree on a way of exchanging that client ID. Which at it's simplest is what OAuth 2 does with bearer tokens. If you have no use for the other parts of the spec then just ignore them, it's all optional and you only need to implement it if you need it.
dpres 15y ago
Sounds like your saying, "Don't use OAuth because it's bloated, create your own API auth protocol and make everyone use that non-standard protocol for my API". That forces developers to implement "custom" protocols per API that may actually be worse than OAuth. You must not be developer. OAuth 2.0 is not bloated and pretty much 2 steps with a clause to never use it via HTTP. How could it be more simple?