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.

> 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.

Thats why OAuth2.0 protocol is limited to HTTPS and is said to never be implemented over HTTP.

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.

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?

Can you explain how would that work?

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.

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?

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.

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.