The majority of failed OAuth 1.0 implementation attempts were unsuccessful due to the cryptographic requirements of the protocol. The complexity of OAuth 1.0 signatures was a major pain point for anyone coming from the simplicity of username/password authentication.

Developers used to be able to quickly write Twitter scripts to do useful things by using just their username and password. With the move to OAuth 1.0, these developers were forced to find, install, and configure libraries in order to make requests to the Twitter API since it requires cryptographic signing of each request.

With the introduction of OAuth 2.0 Bearer tokens, it is again possible to quickly make API calls from a cURL command. The access token is used instead of a username and password.

For example, before OAuth, you may have seen examples in API docs such as:

curl --user bob:pa55 https://api.example.com/profile

With OAuth 1 APIs, it become no longer possible to hard-code an example like this, since the request must be signed with the application’s secret. Some services such as Twitter started providing “signature generator” tools in their developer websites so that you could generate a curl command from the website without using a library. For example, the tool on Twitter generates a curl command such as:

curl --get 'https://api.twitter.com/1.1/statuses/show.json' \
--data 'id=210462857140252672' \
--header 'Authorization: OAuth oauth_consumer_key="xRhHSKcKLl9VF7fbyP2eEw", oauth_nonce="33ec5af28add281c63db55d1839d90f1", oauth_signature="oBO19fJO8imCAMvRxmQJsA6idXk%3D", oauth_signature_method="HMAC-SHA1", oauth_timestamp="1471026075", oauth_token="12341234-ZgJYZOh5Z3ldYXH2sm5voEs0pPXOPv8vC0mFjMFtG", oauth_version="1.0"'

With OAuth 2.0 Bearer Tokens, only the token itself is needed in the request, so the examples again become very simple:

curl https://api.example.com/profile -H "Authorization: Bearer XXXXXXXXXXX"

This provides a good balance between ease of use of APIs and good security practices.