Oauth1.0 introduction

background

Why OAuth What about authorization ?

The most typical application scenario is when a third party logs in , We have developed a website that we hope users can QQ Sign in , But how can I get the user's QQ Information? ? Users will The account number and password tell us that of course , But this has the following hidden dangers :

• We got the user's password , It's not safe . And any application is hacked , All relevant sites are affected
• QQ Password login is required , But simple password login is not safe . Therefore, it further affects QQ Security issues
• After we get the password , It is equivalent to having all the information of the user , In this way, permission restriction cannot be performed
  • Maybe you just want to authorize the user name and avatar , But it was explained together with the list of friends
• Once the user changes the password , All previously authorized applications are invalid

For the above reasons , We need such a mechanism :

• Not password based authorization
• Authorization has a time limit , And you can withdraw your permission at any time
• Revoke the permission of a single application , Will not have any impact on other authorized applications
• You can grant only individual permissions , Not all

you 're right , OAuth It was put forward to solve this problem .

Introduce

OAuth What is it? ? stay RFC file This is how it was introduced in .

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.

It's more official , In short , Is to authorize others to have temporary access to resources .

that , OAuth1.0 How to implement such a mechanism ?

Realization

Before introducing its implementation , You need to know OAuth Some concepts in .

• role
  • Consumer consumer , Applications that require access to resources
  • ServiceProvider Service providers , A server that provides resources
  • User user

Still use our example above , Our blog website needs access to QQ Sign in . ad locum , Blog website is one of them Consumer, and QQ The server is ServiceProvider 了 . For immediate convenience , Hereinafter referred to as Bokee.com QQ The server . The process of obtaining authorization is roughly shown in the figure below :

Introduce each process

technological process

Before the request , Blog sites need to go to QQ The server To register , And obtain the following identification :

• consumer_key: Website identifier
• consumer_secret: The private key used by the website

1. obtain request_token

Website to QQ The server requests a temporary credential , Used to verify during this authorization process .

Portability parameter

• oauth_consumer_key
• oauth_signature_method: Signature generation method
• oauth_signature: The signature of this request , Use consumer_secret Generate
• oauth_timestamp Time stamp , Used to verify this request
• oauth_callback Callback Links , It is used to call back and notify consumers after user authorization
• oauth_nonce Random string
  • This parameter is used to prevent replay attacks , That is, someone gets the request link and asks again
  • therefore , The service provider will verify whether it has been processed

Return the data

• request_token: this token It is only used for verification in the following authorization , And identify this authorization
• request_secret: Subsequent requests for this authorization are encrypted , Used in Section 5 Step

2. Redirect to the server authorization page

Redirect the page to QQ The server Authorization page .

Portability parameter

• request_token: Used to direct to QQ The server identifies this authorization

3. The user is in QQ The server completes the authorization operation

The user is in QQ Login and authorize from the authorization page of the server

4. The callback function notifies that the authorization is successful

After successful user authorization , QQ The server redirects the link to The first step specifies Callback Links . And attach the result to the callback link :

• request_token: Used to identify this authorization . After all, when a blog site receives a callback , You need to know which user authorized successfully .
• verifier: Get... In the next step access_token Used in inspection . The specific functions will be explained in the next step .

5. Obtain after authorization access_token + access_secret

At this point, the user has agreed to grant permission , Blog sites can go to QQ The server has obtained the authorization code of the user .

Return the data

• access_token
• access_token_secret

The user then uses these two authorization information to QQ Server requests resources .

access_token_secret effect

Here's a little question , Given the access_token, And why access_token_secret Well ?

Because accessing data uses HTTP agreement , There is no security guarantee for the data transmission process . When accessing resources later , If only use consumer_secret Sign the request , if consumer_secret Leaked , Then the attacker only needs to get the user's access_token You have their rights . and access_token You also need to carry the permission identification in the parameter when accessing . Therefore, it is very dangerous .

When generating a signature , Plus access_token_secret To sign , and access_token_secret Will not be passed in subsequent visits , Each user is different , So even if consumer_secret Leaked , An attacker cannot gain the privileges of all users .

Portability parameter

• consumer_key
• request_token
• signature_method
• timestamp
• nonce
• verifier
• signature

verifier effect

that , there oauth_verifier It is necessary? ? In fact, it is to prevent session Fixed line attack , Interested can search "OAuth Session Fixation Attack" Check the details . Here is a brief introduction .

hypothesis , An attacker has monitored your network requests , Because of the use of HTTP agreement , There is no secret in plain text . Then the attacker can obtain this authorization in the first step request_token. At the same time, the attacker uses brute force or other methods , To obtain the consumer_secret.

here , If there is no verifier Parameters , All the parameters of this request can be constructed by the attacker . If the attacker frequently accesses this request , And just in the gap between the completion of user authorization and the callback of the website, a legal access was initiated , You will successfully obtain the user's access_token.

By adding random verifier Can make this request unpredictable .

problem

about OAuth1.0 Some problems of implementation :

• Used HTTP agreement , Low security
• Use HTTP agreement , The authenticity of the service provider is not verified
• Right web application ( Such as Android ) Support is unfriendly . ( It also passed PIN Code implementation , I'm not going to introduce it here )
• The signing process is complex . It needs to be used at the same time consumer_secret+access_token_secret To sign . ( It's also because of the use of HTTP agreement )

These questions are OAuth2.0 It's solved , See the next article for details : OAuth2.0 Introduce