The OAUTH protocol provides a secure, open and simple standard for the authorization of user resources. The difference from the previous authorization method is that the authorization of OAUTH will not allow the third party to access the user's account information (such as user name and password), that is, the third party can apply for the user's resource without using the user's user name and password. authorization, so OAUTH is safe. oAuth is short for Open Authorization.
The OAUTH protocol provides a secure, open and simple standard for the authorization of user resources. At the same time, any third party can use the OAUTH authentication service, and any service provider can implement its own OAUTH authentication service, so OAUTH is open. The industry provides a variety of OAUTH implementations such as PHP, JavaScript, Java, Ruby and other language development kits, which greatly saves the programmer's time, so OAUTH is simple. Many Internet services such as Open API, and many large companies such as Google, Yahoo, Microsoft, etc., have provided OAUTH authentication services, which are enough to show that the OAUTH standard has gradually become the standard for open resource authorization.
On the homepage of the official website, you can see the following introduction:
An open protocol to allow secure API authorization in a simple and standard method from web, mobile and desktop applications.
It roughly means that OAUTH is an open protocol that provides a simple, standard way for desktop, mobile or web applications to access API services that require user authorization. OAUTH is similar to Flickr Auth, Google's AuthSub, Yahoo's BBAuth, Facebook Auth, etc.
OAUTH protocol features
(1). Simple: It is easy to understand and use whether it is an OAUTH service provider or an application developer;
(2). Security: no information such as user keys is involved, which is more secure and flexible;
(3). Open: any service provider can implement OAUTH, and any software developer can use OAUTH;
OAUTH principle
The first step: the user visits a third-party website, such as: the website you need to use QQ to log in;
Step 2: After you click QQ to log in, the third-party website will connect and make a request. For example, after you click to log in, the third-party website will jump to the QQ platform, prompting you to log in;
Step 3: You need to authorize a third-party website to access your information. For example, when you successfully log in to QQ, QQ will prompt you whether to authorize a third-party website to access your basic user information or other resource information. , then you can click Authorize;
Step 4: After authorization, the third-party Web can access the resource information you just authorized, such as: your QQ basic information - avatar, nickname, gender, etc.
related terms
three URLs
Request Token URL: Get the unauthorized Request Token service address;
User Authorization URL: Get the Request Token service address authorized by the user;
Access Token URL: Exchange the authorized Request Token for the service address of the Access Token;
Step 1: The website requests an unauthorized Token from the authentication platform. This Request Token Url is the first Url mentioned above;
Step 2: Jump to the user authorization page, prompt the user to log in and authorize, and return to the authorized Token. The User Authorization Url used is the second Url mentioned above;
Step 3: Request Access Token (data token) from the authentication platform through the authorized Token. The Request Access Url used is the third Url mentioned above. After returning to this step, the whole authentication process is over. Finally, The first step is to call the interface to obtain user information through parameters such as data tokens, which is not a complete authentication process. (I like simplicity and clarity, the certification process is like this, I believe you can understand it through the illustrations and explanations, if there is anything you don’t understand, please leave a message)
parameter definition
OAUTH_consumer_key: User ID, the direct user of OAUTH service is the application developed by the developer. Therefore, the acquisition of the parameter value is generally to register an application with the OAUTH service provider, and then obtain the OAUTH_consumer_key of the application.
OAUTH_consumer_secret: The secret corresponding to OAUTH_consumer_key.
OAUTH_token: A "token" obtained by OAUTH in the last step, through this "token" request, you can go to the website that owns the resource to grab any resource that has permission to be grabbed.
OAUTH_token_secret: The private key corresponding to OAUTH_token.
OAUTH_signature_method: The signature method of the request string. The application must sign the request every time it sends a request to the three service addresses of OAUTH. There are three signature methods: HMAC-SHA1, RSA-SHA1 and PLAINTEXT.
OAUTH_signature: Sign the request with the above signature method.
OAUTH_timestamp: The timestamp when the request was initiated, the value is the number of seconds since 1970 00:00:00 GMT, and must be an integer greater than 0. The timestamp of this request must be greater than or equal to the last timestamp.
OAUTH_nonce: A randomly generated string used to prevent repetition of requests and illegal attacks from the outside world.
OAUTH_version: The version number of OAUTH.
response code
HTTP 400 Bad Request request error
Unsupported parameter parameter error
Unsupported signature method signature method error
Missing required parameter parameter is missing
Duplicated OAUTH Protocol Parameter
HTTP 401 Unauthorized Unauthorized
Invalid Consumer Key 非法key
Invalid / expired Token Invalid or illegal token
Invalid signature Invalid signature
Invalid / used nonce illegal nonce
Certification process
Get unauthorized request token
Request parameters:
OAUTH_consumer_key: Consumer key value.
OAUTH_signature_method: The signature method used by the consumer to sign this request.
OAUTH_signature: Signature, defined in Signing Request (Signing Request).
OAUTH_timestamp: Defined in Nonceand Timestamp (single value and timestamp).
OAUTH_nonce: Defined in Nonceand Timestamp (single value and timestamp).
OAUTH_version: Optional.
Extra parameters: any extra parameters defined by the service provider
The server returns the result, and the response contains the following parameters:
OAUTH_token: request token
OAUTH_token_secret: token secret
Additional parameters: Arbitrary parameters defined by the service provider.
Get the request token authorized by the user
Request parameters:
OAUTH_token: Optional. The request token obtained in the previous steps. The service provider MAY declare this parameter as required, or allow it not to be included in the authorization URL and prompt the user for manual input.
OAUTH_callback: Optional. The consumer can specify a URL, and the service provider will redirect the user to this URL after obtaining user authorization (obtaining user authorization) successfully.
Additional parameters: Arbitrary parameters defined by the service provider.
The service provider directs the user back to the consumer
If the consumer provides the callback URL in OAUTH_callback (described in the consumer guides the user to the service provider (the consumer guides the user to the service provider)), the service provider constructs an HTTP GET request URL to redirect the user's browser to the URL and include the following parameters:
OAUTH_token: The request token authorized or denied by the user
The callback URL can contain query parameters provided by the consumer, and the service provider must keep the existing query unchanged and append the OAUTH_token parameter.
Exchange the authorized request token for the Access Token
Consumer request access token parameters:
OAUTH_consumer_key: Consumer key value.
OAUTH_token: The request token obtained before.
OAUTH_signature_method: The signature method used by the consumer.
OAUTH_signature: Signature defined in Signing Request (Signing Request).
OAUTH_timestamp: Defined in Single Value and Timestamp (Single Value and Timestamp).
OAUTH_nonce: Defined in single value and timestamp (single value and timestamp).
OAUTH_version: version number, optional.
Return parameter:
OAUTH_token: Access token.
OAUTH_token_secret: Token secret.
Access protected resources
Request parameters:
OAUTH_consumer_key: Consumer key value.
OAUTH_token: Access token.
OAUTH_signature_method: The signature method used by the consumer.
OAUTH_signature: Signature defined in Signing Request (Signing Request).
OAUTH_timestamp: Defined in single value and timestamp (single value and timestamp).
OAUTH_nonce: Defined in single value and timestamp (single value and timestamp).
OAUTH_version: version number, optional.
Additional parameters: Additional parameters specified by the service provider.
Authorization process
After clarifying the terms of OAUTH, we can have a preliminary understanding of the process of OAUTH authentication and authorization. In fact, to put it simply,
There are three steps in OAUTH authentication and authorization, which can be summarized in three sentences:
1. Get an unauthorized Request Token
2. Obtain the Request Token authorized by the user
3. Exchange the authorized Request Token for the Access Token
After the application obtains the Access Token, it has the right to access the resources authorized by the user. As you may have seen, these three steps are not the three URL service addresses corresponding to OAUTH. That's right, in the above three steps, each step requests a URL and receives relevant information, and gets the relevant information of the previous step to request the next URL until the Access Token is obtained.
The specific execution information of each step is as follows:
A. The user (third-party software) requests an unauthorized Request Token from the OAUTH service provider. To initiate a request to the Request Token URL, the parameters that the request needs to bring are shown in the figure above.
B. The OAUTH service provider agrees to the user's request, issues an unauthorized oauth_token and the corresponding oauth_token_secret to the user, and returns it to the user.
C. The user requests the Request Token authorized by the user from the OAUTH service provider. Make a request to the User Authorization URL, and request to bring the unauthorized token and key obtained in the previous step.
D. The OAUTH service provider will guide the user to authorize. The process may prompt the user which protected resources you want to authorize to the app. This step may or may not return an authorized Request Token. Such as Yahoo OAOAUTH will not return any information to the user.
E. After the Request Token is authorized, the user will initiate a request to the Access Token URL and exchange the Request Token authorized in the previous step for an Access Token. The parameters of the request are shown in the figure above. This one more parameter than the first step A is the Request Token.
F. The OAUTH service provider agrees to the user's request, issues an Access Token and the corresponding key to it, and returns it to the user.
G. The user can use the Access Token returned in the previous step to access the resources authorized by the user in the future.