User authentication and authorization

Overview

Because the project involved user authentication and authorization , so a good summary of this piece.

Certifications and authorizations

In general, we say that the authentication mainly refers to the user login authentication ; Generally we say that the authorization is mainly third party authorization .

There are 2 main methods for user login authentication, one is based on Session-id authentication and the other is token-based authentication.

Third-party authorization is mainly the authorization of the Oauth2.0 standard, it mainly includes authorization Code mode authorization and Simple mode authorization.

Session-id-based certification

Session-id-based authentication is a more traditional way of authentication, and it consists of the following steps :

1. The user enters a user name and password to send to the server.
2. The server verifies this user name and password, generates a session ID (Session-id) If successful, and then saves the session ID in both the server and browser cookie. This authentication method is also known as cookie-based authentication because it is a browser cookie.
3. Each time a user requests a resource, the session ID is sent to the server, the server side finds the session ID locally, and if it can find it, it returns the data requested by the user.
4. When the user exits the login, the session is destroyed both on the client and server side.

For this approach, our front-end is handled as follows:

1. Sends a user name and password to the server and receives the session ID returned by the server.
2. The server automatically stores the session ID in the browser's cookie and does not require our front-end processing.
3. Because the data in the cookie is automatically taken when the HTTP request is sent, there is no need for the front-end special handling when sending other HTTP requests.
4. When the user logs out (note that the user is actively logged out or logged out), the front end needs to request a logout interface, and the server destroys the session ID stored in the browser cookie.

It is important to note that all of the above is done by the server, the front-end only requests the interface on the line. The server can write the session ID itself into the browser's cookie.

Token-based authentication

Token-based authentication mainly refers to the JSON Web token authentication, or JWT authentication.

It mainly consists of the following steps :

1. The user enters a user name and password to send to the server.
2. The server authenticates the user name and password, and succeeds returns a token (which can be considered a long string) to the browser.
3. Each subsequent request, the browser sends token to the server, the server verifies that token is valid, and returns the data requested by the user.
4. When the user exits the login, the browser side destroys the token on the line.

It should be noted that JWT certification has a very important feature: The server side does not store tokens.

Why does the server not need to store tokens, let's look at the token generation process.

JWT This string is made up of three parts: header (header), payload (body information), signature (signature).

The head is the basic information for the JWT, which is then obtained by encrypting (Base64 encryption). The original information can be obtained by decryption. For example, the following basic information: type is JWT, Signature algorithm is HS256.

{  "typ": "JWT",  "alg": "HS256"}

After the encryption, the header is as follows:

ewogICJ0eXAiOiAiSldUIiwKICAiYWxnIjogIkhTMjU2Igp9

The principal information is the information that describes the user, which is then obtained by encrypting (Base64 encryption). The original information can be obtained by decryption. For example, the following subject information.

{    "iss": "Yang JWT",    "iat": 1441593502,    "exp": 1441594722,    "aud": "www.example.com",    "sub": "[email protected]",    "from_user": "B",    "target_user": "A"}

The following encrypted principal information is as follows:

ew0KICAgICJpc3MiOiAiWWFuZyBKV1QiLA0KICAgICJpYXQiOiAxNDQxNTkzNTAyLA0KICAgICJleHAiOiAxNDQxNTk0NzIyLA0KICAgICJhdWQiOiAid3d3LmV4YW1wbGUuY29tIiwNCiAgICAic3ViIjogInlhbmdAZXhhbXBsZS5jb20iLA0KICAgICJmcm9tX3VzZXIiOiAiQiIsDQogICAgInRhcmdldF91c2VyIjogIkEiDQp9

Connect the above encrypted 2-segment string with a dot number, as follows:

ewogICJ0eXAiOiAiSldUIiwKICAiYWxnIjogIkhTMjU2Igp9.ew0KICAgICJpc3MiOiAiWWFuZyBKV1QiLA0KICAgICJpYXQiOiAxNDQxNTkzNTAyLA0KICAgICJleHAiOiAxNDQxNTk0NzIyLA0KICAgICJhdWQiOiAid3d3LmV4YW1wbGUuY29tIiwNCiAgICAic3ViIjogInlhbmdAZXhhbXBsZS5jb20iLA0KICAgICJmcm9tX3VzZXIiOiAiQiIsDQogICAgInRhcmdldF91c2VyIjogIkEiDQp9

Then the above string to HS256 algorithm encryption, encryption requires us to provide a key (for example, we set the key is 63161014009), the encrypted content is the signature:

rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

Finally, we put the signature through the dot and got the token at the end:

ewogICJ0eXAiOiAiSldUIiwKICAiYWxnIjogIkhTMjU2Igp9.ew0KICAgICJpc3MiOiAiWWFuZyBKV1QiLA0KICAgICJpYXQiOiAxNDQxNTkzNTAyLA0KICAgICJleHAiOiAxNDQxNTk0NzIyLA0KICAgICJhdWQiOiAid3d3LmV4YW1wbGUuY29tIiwNCiAgICAic3ViIjogInlhbmdAZXhhbXBsZS5jb20iLA0KICAgICJmcm9tX3VzZXIiOiAiQiIsDQogICAgInRhcmdldF91c2VyIjogIkEiDQp9.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

The above three encryption is reversible , where the head and the principal information can be decrypted with Base64, the signature requires a key to decrypt. A hacker cannot forge a signature without a key, so it cannot forge tokens. Then, on the server side only need to re-the header and the principal information in the token with the key encryption once, and then compare with the signature, you can know that the token is not legitimate. So there's no need to place tokens locally.

Since the server does not need to place tokens locally, the time to find tokens is saved, and when the user is logged out, the server does not need to destroy tokens and other additional processing. So JWT reduces a lot of stress on the server.

It is worth mentioning that the above only illustrates a model of JWT, the process can be based on the actual situation of the process of transformation. For example, some businesses put tokens in the HTTP header to send to the server, and some businesses put tokens into the URL parameters sent to the server.

Although JWT has many advantages over Session-id, it does not solve the JWT failure unless the expiration time is set. That is, if the token is stored in the server, it can solve the problem: if I store tokens in Redis, each time the authentication of the token, so that you can do, user A with a information login, User B then use a information log, Then user A's login will expire because a new token is stored (token received by User B). But JWT can't do this.

So, JWT is only available for very short-term token!!! It can not replace session-id!!!

Hybrid authentication

Because Session-id-based authentication has the following drawbacks:

1. All rely on the service side to complete, the service side has the state, the pressure will be very big.
2. For cross-domain requests, cookies are not automatically sent.

JWT-based certifications also have the following drawbacks:

1. You can only revoke tokens by setting a validity period, and if the token is set to expire for too long, there is no way to abolish the token during that period.

So for the general certification, now usually with a hybrid method , specifically as follows:

1. The user enters a user name and password to send to the server.
2. The server verifies the user name and password, succeeds in returning a token to the browser, and stores the token and the user name in the server.
3. Each subsequent request, the browser will send token to the server, the server to receive token and local comparison, the same return the user requested data.
4. Each time the user logs back in, the server regenerates a token and clears the previous token and stores it.
5. When the user exits the login, the browser destroys the token and the server does not process it.

The advantages of this certification are:

1. The server only needs to generate and store tokens, the pressure will be much smaller, considering the access speed, you can use Redis to store tokens, so that the reading and lookup will be very fast.
2. The server has no status and is also suitable for restful APIs.

Authorization for Authorization Code mode

The Authorization Code mode is the most exciting licensing mode in Oauth2.0. Its steps are as follows:

For example, users need to register in the watercress, want to use the user's QQ information to register, this time need to obtain the third party QQ authorization, and take the QQ inside this user's information.

1. User access to the watercress, watercress will be user-oriented QQ authentication Server page.
2. The user chooses to agree to the authorization of QQ.
3. The authentication Server page of QQ directs the user to the "redirect URI" specified by the watercress, and an Authorization Code (code) is attached.
4. Watercress Specifies the redirect URI to use the authorization code, plus the server ID and password stored in the redirect Uri, to request tokens from the QQ authentication server.
5. The authentication server of QQ checks authorization code, server ID and password, and sends tokens (token) to "redirect Uri" after confirming the error.
6. The redirect URI uses the token to request user information from the QQ resource server, and then registers the user with the watercress.
7. User registration in the watercress is complete. (Users are not required to fill in any user information)

Here are a few things to note:

1. Hackers do not even get the second step of the authorization code is useless, because the hacker does not have a server ID and password, so hackers can not access the QQ server user information.

2. What is the server ID and password? The server ID and password are watercress's "redirect Uri" when registering with the authentication server of QQ to obtain the ID and password, as the logo of the watercress. At the time of registration, QQ authentication server will also store this "redirect Uri", so different users will be directed to the same "redirect URI."

3. The request in step 4th must be requested with HTTPS, otherwise the authorization code, the server ID and password may be intercepted by the hacker, and the token sent back by the authentication server may also be intercepted.

4. Why do I need a "redirect uri"? First, the Watercress server ID and password can not be stored in other pages, it can only be stored in the watercress "redirect Uri", or it is likely to be leaked. Second, the "redirect Uri" and the authentication server communication must be HTTPS, the general Watercress page communication with the authentication server may not be https.

5. In the 6th step, the redirect URI may send the token back to the original Watercress page, or it may create a watercress token to send back to the original page.

6. Oauth2.0 also has a refresh_token. The general QQ authentication server sends back the token the validity period is very short, and the refresh_token validity period is relatively long, therefore when the token expires, may through the Refresh_token to the QQ authentication server to apply token.

7. A total of 3 users to do a URI jump, one is to jump to the authentication server QQ. The second time is to jump to the redirect URI. The third time jumps back to the previous page. First of all, users need to operate, click whether to agree to QQ authorization; the second time does not require user action, automatic third jump.

Authorization for Simple Mode

The Simple mode is to request token directly from the authentication server without using the redirect URI. Or in the case of watercress and QQ, its steps are as follows:

1. User access to the watercress, watercress will be user-oriented QQ authentication Server page.
2. The user chooses to agree to the authorization of QQ.
3. The authentication Server page of QQ directs the user to the "redirect URI" specified by the watercress, and the token is attached directly to the hash portion of the URI.
4. The redirect URI uses the token to request user information from the QQ resource server, and then registers the user with the watercress.
5. User registration in the watercress is complete. (Users are not required to fill in any user information)

Here are a few things to note:

1. The difference between authorization and authorization code mode is that there is no authorization code, so the server ID and password are not detected.

2. Hackers can attack in these 2 ways: 1. The hacker intercepts the token directly. 2. Hackers forge a third-party website, and then guide users to a bogus third-party site authorization, and finally can be taken for granted token. Authorization of the Authorization Code mode prevents the second attack, but also prevents the first attack (which can be enhanced with HTTPS).

3. Authorization code mode and simple mode authorization in order to prevent CSRF attacks, the URI of the jump is added with a state parameter to verify.

4. The silent authorization and this almost, just no second step, directly by default agree to authorize.

5. URL jumps will leave a white stripe underneath the Safari browser, and a non-URL URI jump will not. Because the non-silent authorization jumps to a URL where the user confirms the authorization, the non-silent authorization leaves a white stripe and the silent authorization does not. (Not because there is code to leave the White Stripes)

6. Why is there a token attached to the hash section? Because the browser handles the hash parameter without reloading the page. (Although the new History API will solve this problem.) ）

7. If the authentication server does not support cross-domain, then only simple mode authorization can be used. Because authorization of the authorization Code mode submits the server ID, password and code to the authentication server, the authentication server is required to support cross-domain post requests, but the simple mode authorization is all URI jumps, so don't worry about cross-domain.

User authentication and authorization