OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end- user). It also provides a process for end-users to authorize third- party access to their server resources without sharing their credentials (typically, a username and password pair), using user- agent redirections.
This section will help developers understand the concepts in OAuth 1.0, but not in deep. Here is an overview of a typical OAuth 1.0 flow:
It takes more steps to obtain an access token than OAuth 2.0.
There are usually three roles in an OAuth 1.0 flow. Let’s take Twitter as an example, you are building a mobile app to send tweets:
During the OAuth 1.0 process, there are several credentials passed from server to client, and vice versa.
Let’s take your mobile Twitter app as an example. When a user wants to send a tweet through your application, he/she needs to authenticate at first. When the app is opened, and the login button is clicked:
And then Client can send tweets with the token credentials.
In OAuth 1.0, every request client sending to server requires a signature. The signature is calculated from: