Recently, I have been reconstructing the front-end code of the company's previous products, abandoning the previous session-cookie authentication method and adopting token authentication. I felt it was necessary to sort out several common authentication methods in my busy schedule.

Currently we have four commonly used authentication methods:

HTTP Basic Authentication

session-cookie

Token verification

OAuth (Open Authorization)

1. HTTP Basic Authentication

This authorization method is complied by the browser

2. The server sends verification request code 401 to the client (WWW-Authenticate: Basic realm="google.com" is the key. If there is no client, the user name and password input interface will not pop up). The data returned by the server is roughly as follows: < /p>

HTTP/1.0 401 Unauthorised

Server: SokEvo/1.0

WWW-Authenticate: Basic realm=”google.com”

Content -Type: text/html

Content-Length: xxx

3. When complying with

Authorization: Basic d2FuZzp3YW5n

Note: d2FuZzp3YW5n represents the encrypted username and password (username: password and then encrypted through base64. The encryption process is the default behavior of the browser. We do not need to manually encrypt, we only need to enter the username and password)

5. After receiving the above request information, the server takes out and decrypts the user information after the Authorization field, and compares the decrypted user name and password with the user database for verification. If the user name and password are correct, the server will provide the requested resources according to the request. Sent to the client

Effect:

When the client is not authenticated, the username and password input box will pop up. At this time, the request is in the pending state. At this time, the service is actually the user. When entering the username and password, the client will send the request with the Authentication header again.

Authentication successful:

server.js

let express = require("express");

let app = express() ;

app.use(express.static(__dirname+'/public'));

app.get("/Authentication_base",function(req,res){

console.log('req.headers.authorization:',req.headers)

if(!req.headers.authorization){

res.set({

'WWW-Authenticate':'Basic realm="wang"'

});

res.status(401).end();< /p>

}else{

let base64 = req.headers.authorization.split(" ")[1];

let userPass = new Buffer(base64, ' base64').toString().split(":");

let user = userPass[0];

let pass = userPass[1];

res.end("OK");

}else{

res.status(401).end();

}

}

})

app.listen(9090)< /p>

index.html:

< meta charset="UTF-8">

Of course you have to log in After logging out, we will find that after successful authentication, each request header will bring Authentication and its content. So how to invalidate this login?

After searching online for a long time, the most effective way at present is to set up a special logout account on the server during the logout operation. When the Authentication information received is the logout username and password, correct it. The logout is successful, and when the client performs the logout operation, it manually modifies the Authentication in the request header and sets it to the default logout account and password of the server.

Through the above simple explanation, we can actually realize the shortcomings of this verification method. The encryption method is simple, just base64 encryption, and this encryption method is reversible. At the same time, username and password information will be attached to the header of each request, so that it can be easily detected by sniffers on the external network.

Summary:

Officially because of this, this encryption method is generally used in systems with low internal security requirements, but it is relatively common. Generally speaking, now This type of authentication is rarely used.

If the project needs to be deployed on the public network, this method is not recommended. Of course, you can also encrypt the transmission with SSL, which will be better. I will study this later if I have time.

2.session-cookie

The second method is to use the server-side session (session) and the browser-side cookie to achieve front-end and back-end authentication. Due to /oauth2.0/show ?which=Login&display=pc&response_type=code&client_id=100270989&redirect_uri=/oauth2.0/show?which=Login&display=pc&response_type=code&client_id=100270989&redirect_uri=/account/login?oauth_provider=QQProvider&state=test

We can use this url address See several common parameters of Auth2.0:

response_type, return type

client_id, third-party application id, issued by the authorization server (qq) to the third-party application when it is submitted Third party applications.

redirect_uri, login successful redirect page

oauth_provider, third-party authorization provider

state, random code given by third-party application

Step 2. Return the user credential (code) and return a credential (code). When the user clicks authorization and logs in, the authorization server will generate a user credential (code). This user credential will be appended to the redirected address redirect_uri

/account/login?code=9e3efa6cea739f9aaab2&state=XXX

Step 3. Request authorization from the authorization server:

After the second step of obtaining the code, the subsequent work can be handed over to the background for processing, and the interaction with the user is over. Next, I need to obtain the Access Token, which we need to use to obtain user information and other resources from the authorization server.

The third-party application background requests the Access Token from the authorization server through the second step of the certificate (code). At this time, the following information is required:

client_id identifies the id of the third-party application. Issued by the authorization server (Github) to the third-party application when the third-party application is submitted

client_secret The security certificate between the third-party application and the authorization server, issued by the authorization server (Github) when the third-party application is submitted. To the third-party application

code The user credential returned in the first step redirect_uri The address to jump to the second step after generating the user credential in the first step

state Given by the third-party application The random code generated

Step 4. After the authorization server agrees to the authorization, it returns a resource access credential (Access Token).

Step 5. The third-party application requests related resources from the resource server through the credentials (Access Token) in step 4.

Step 6. Resource server verification credentials (Access Token) passed