Choosing an OAuth Type for Your API
Open Authentication (OAuth) is an authentication protocol that allows to let applications perform certain operations on your behalf without sharing your password.
It was introduced to help avoid the security risks that using basic authorization could lead to, as it simply asked for username and password that were then forwarded to the API. All the private information held by and accessible to the software utilizing your API could be used maliciously once it is hacked. OAuth is token-based which means that it prevents the user information from being exposed to the API client.
There are two versions of OAuth, each having its strengths and weaknesses. It is important to understand the crucial difference between these types before choosing one, as your decision might affect security and usability. That is why we are going to draw a line between them.
Generally speaking, OAuth 1.0 (also known as RFC 5849) is believed to be more secure, though less flexible and more complex. It is based on having shared secrets between the consumer and the server that are used to calculate signatures. The latter then allow the server to verify the authenticity of API requests.
This type of OAuth includes extra steps if compared to OAuth 2.0. It requires that the client ask the server for a request token. This token acts like the authorization code in OAuth 2.0 and is what gets exchanged for the access token. You can see the OAuth 1.0 flow in the picture below.
A considerable advantage of OAuth 1.0 is that you never pass the token secrets across the wire directly, which makes it impossible for anyone to see a password in transit. Plus, it is safe without SSL though it is preferable if the data transferred is sensitive. The security level OAuth 1.0 provides requires some effort to generate and validate signatures. You will have to use specific hashing algorithms with a strict set of steps which is not that harassing, as many programming languages have libraries to handle this for you.
Here you can find an interactive explanation with customizable inputs.
Unlike OAuth 1.0, the second version does not require signatures and relies on SSL instead, which makes the reason for why it is believed to be less secure. The positive moment here is that this makes OAuth 2.0 easier to implement for third parties.
The problem with SSL is that the connection still works even if you fail to verify the certificate. You can also make a typo that will void the security of the token. Despite the fact that much has been said and written about OAuth 2.0 being a road to hell, it is used by many companies.
An important point to mention is that the second version is more flexible, as it lets users choose the actions the calling application can access. This serves as a limit to what third parties can do with user information.
See the OAuth 2.0 flow below.
Both OAuth 1.0 and OAuth 2.0 are good in their own way. The inference is it is only you who can decide which is better for you.
P.S.: Gregory Brail and Brian Pagano shared a presentation you may also find helpful.