Introducing several commonly used web security authentication methods

This article introduces five commonly used web security authentication methods, which has certain reference value. I hope it can be helpful to everyone.

1. Http Basic Auth

This is the oldest security authentication method. This method is to simply bring the accessed username and password when accessing the API. Since the information will It was exposed, so it is used less and less now. More secure and confidential authentication methods are now used. Some old platforms may still use it.

As shown in the picture below, a box will pop up asking you to fill in your username and password. This is the HTTPBasic authentication that comes with Tomcat.

This is your credential for accessing the application. The xxxXXX string was written by me to indicate that it is a ciphertext. What kind of ciphertext is this? The username and password are ciphertext obtained after Base64 encryption. So do you feel the same way now - it's too easy to steal, so new applications rarely use this method now. Although it is simple, the security level is too low.

2. OAuth2

My previous blog introduced OAuth2 and the use of Azure AD to implement OAuth2 authentication. Here, I will extract part of the content from that blog for everyone to summarize and review.

https://blog.csdn.net/aHardDreamer/article/details/88650939

OAuth is: Open Authrization (Open Authorization). It is an open standard that allows users to let third-party applications access the user's private resources stored on a website without providing the user name and password to Third parties. For example, we are familiar with logging in to third-party platforms through QQ/WeChat/Weibo, etc. There were many security holes after the OAuth 1.0 version was released, so OAuth 1.0 was completely abolished in OAuth 2.0, which focused on simplicity for client developers, or through an approved agreement between the resource owner and the HTTP service provider. The interaction acts on behalf of the user, or allows a third-party application to gain access on the user's behalf. It's a bit convoluted to read, but the principle is actually very simple. Please see the explanation below.

1. First, we need to understand these three roles in the OAuth2 authentication and authorization process:

1. Service provider: As the name suggests, users provide protected services and resources. There are a lot of things stored in here.

2. User: A person who has stored things (photos, information, etc.) on the service provider.

3. Client: The service caller. If it wants to access the resources of the service provider, it needs to register with the service provider, otherwise the service provider will not accept it.

2. OAuth2 authentication and authorization process:

1) The user wants to operate the resources stored in the service provider;

2) The user logs in to the client, and the client The service provider requests a temporary token;

3) After the service provider verifies the client's identity, it gives it a temporary token;

4) After the client obtains the temporary token, it directs the user to The service provider's authorization page and requests user authorization. (In this process, the temporary token and the client's callback link/interface will be sent to the service provider---obviously the service provider will come back to call this interface after user authentication and authorization)

5 ) The user enters the username and password to log in. After successful login, the client can be authorized to access the service provider's resources;

6) After the authorization is successful, the service provider guides the user to the client's web page (call step 4 Callback link/interface inside);

7) The client obtains the formal access token from the service provider based on the temporary token;

8) The service provider obtains the formal access token based on the temporary token and the user's authorization The client is granted an access token;

9) The client uses the access token to access the user's protected resources stored on the service provider.

3. There are four ways to get access token (Grant Type), each of which has applicable application scenarios:

1. Authorization Code (authorization code mode)

Used in combination with ordinary server-side applications.

1) The user accesses the client, and the latter directs the former to the authentication server. Assuming that the user grants authorization, the authentication server directs the user to the "redirection URI" (redirection URI) specified in advance by the client, and attaches a Authorization code.

2) The client receives the authorization code, attaches the earlier "redirect URI", and applies for a token from the authentication server: GET /oauth/token?response_type=code&client_id=test&redirect_uri=Redirect page link. The request returns a code authorization code successfully, which is generally valid for 10 minutes.

3) The authentication server checks the authorization code and redirect URI. After confirming that they are correct, it sends the access token (access token) and refresh token (refresh token) to the client. POST /oauth/token?response_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=Redirect page link. The request successfully returns access Token and refresh Token.

(Free learning video sharing: php video tutorial)

2. Implicit (simplified mode)

Use in combination with mobile applications or Web Apps.

Access Token is returned directly from the authorization server (front-end channel only)

Refresh tokens are not supported

Assume that the resource owner and the public client application are on the same device

Most vulnerable to security attacks

3. Resource Owner Password Credentials

Applicable to trusted client applications, such as internal or external applications within the same organization External application.

Apps that use username and password to log in, such as desktop App

Use username/password as the authorization method to obtain access token from the authorization server

Generally, refresh token is not supported

Assume that the resource owner and the public client are on the same device

4. Client Credentials

Applicable to the client calling the main service API type Applications (such as Baidu API Store, microservices between different projects call each other)

Only back-end channels, use customer credentials to obtain an access token

Because customer credentials can be symmetric or asymmetric Encryption, this method supports shared passwords or certificates

3. Cookie-Session Auth

Cookie-Session authentication mechanism was compared when we first learned J2EE Mostly, a Session object is created on the server side for a request authentication, and a Cookie object is created on the client's browser side; state management is achieved by bringing the Cookie object brought by the client to match the session object on the server side. By default, cookies are deleted when we close the browser. But you can make the cookie valid for a certain period of time by modifying the expire time of the cookie;

However, this cookie-session-based authentication makes it difficult to expand the application itself. With the increase of different client users, independent The server can no longer host more users, and problems with session-based authentication applications will be exposed at this time.

Problems based on session authentication:

1) Increase in Session will increase server overhead

After each user is authenticated by our application, our application must The server makes a record to facilitate the identification of the user's next request. Generally speaking, the session is stored in memory. As the number of authenticated users increases, the server's overhead will increase significantly.

2) Poor adaptability in distributed or multi-server environments

After user authentication, the server makes authentication records. If the authentication records are saved in memory, this means that the user The next request must be made on this server so that authorized resources can be obtained. This accordingly limits the capabilities of the load balancer in distributed applications. This also means limiting the scalability of the application. However, some servers can now share sessions between each server by setting sticky sessions.

3) Vulnerable to CSRF attacks

Because user identification is based on cookies, if the cookie is intercepted, the user will be vulnerable to cross-site request forgery attacks

4. Token Auth

The token-based authentication mechanism is similar to the http protocol and is stateless. It does not need to retain the user's authentication information or session information on the server. This means that applications based on the token authentication mechanism do not need to consider which server the user logs in to, which facilitates application expansion.

Process:

The user uses the username and password to request the server

The server verifies the user's information

The server sends the user a token through verification

The client stores the token and attaches the token value to each request.

The server verifies the token value and returns the data.

This token must be included in each request. Passed to the server, it should be saved in the request header. In addition, the server must support the CORS (Cross-Origin Resource Sharing) policy. Generally, we can do this on the server: Access-Control-Allow-Origin.

5. JWT authentication mechanism (Json Web Token)

As an open standard (RFC 7519), JWT defines a simple, customizable The included methods are used to securely transfer information between communicating parties in the form of Json objects. Because of the existence of digital signatures, this information is credible, and JWT can be signed using the HMAC algorithm or the RSA public-private key pair.

Simplicity

Can be sent through URL, POST parameters or in HTTP header, because the data volume is small and the transmission speed is fast

Self-contained

The payload contains the information required by all users, avoiding multiple queries to the database

It is very useful to use JSON Web Token in the following scenarios:

Authorization: This is the most common scenario for using JWT. Once the user is logged in, each subsequent request will contain a JWT, allowing the user to access the routes, services, and resources allowed by that token. Single sign-on is a feature of JWT that is now widely used because it has little overhead and can be easily used across domains.

Information Exchange: JSON Web Tokens are undoubtedly a good way to securely transmit information between parties. Because JWTs can be signed, for example, with a public/private key pair, you can be sure that the sender is who they say they are. Additionally, since the signature is calculated using the header and payload, you can also verify that the content has not been tampered with.

Structure of JWT:

Through this picture, it is clear that the structure of JWT is divided into three parts, and they are connected by "." :

Header:

The header typically consists of two parts: the token type ("JWT") and the algorithm name (such as: HMAC SHA256 or RSA, etc.).

For example:

Then, use Base64 to encode this JSON to get the first part of the JWT

Payload:

## The second part of #JWT is the payload, which contains the claims (requirements). Claims are statements about entities (usually users) and other data. There are three types of declarations: registered, public and private.

Registered claims : Here is a set of predefined claims, they are not mandatory, but recommended. For example: iss (issuer), exp (expiration time), sub (subject), aud (audience), etc.

Public claims : Can be defined at will.

Private claims : Claims used to share information between parties who agree to use them, and are not registered or public.

The following is an example:

Base64 encode the payload to get the second part of the JWT

Note, do not include it in the JWT Put sensitive information in the payload or header unless they are encrypted.

Signature:

In order to get the signature part, you must have the encoded header, the encoded payload, a secret key, the signature algorithm is the one specified in the header, and then sign them. Can.

For example:

HMACSHA256(base64UrlEncode(header) "." base64UrlEncode(payload), secret)

The signature is used to verify whether the message has been changed during the delivery process , and, for tokens signed with a private key, it can also verify whether the sender of the JWT is who it claims to be.

When you encounter JWT token, you can go to the JWT official website to decrypt it. Here is the data decrypted by the official website. You can clearly see its three parts:

For more information about JWT, you can go to this blog:

https://www.cnblogs.com/cjsblog/p/9277677.html

Reference:

https://www.jianshu.com/p/f8c43dcd8b69

https://blog.csdn.net/alan_liuyue/article/details/88183267

https://www .cnblogs.com/cjsblog/p/9277677.html

Related recommendations:

web server security

The above is the detailed content of Introducing several commonly used web security authentication methods. For more information, please follow other related articles on the PHP Chinese website!