1. Certification

Into the mobile Internet era, everyone brush every day in the mobile phone, commonly used software has WeChat, alipay, headlines, instruction made an example of WeChat below the certification related basic concept, need to register before the first use of WeChat become WeChat user, then enter account and password to login WeChat, enter account and password login WeChat is the process of certification.

Why is the system authenticated?

Authentication is to protect the privacy of system data and resources. Users can access the system resources only when their identities are valid.

Authentication: User authentication is the process of determining whether a user’s identity is legitimate. When a user accesses system resources, the system requires authentication. If the user’s identity is legitimate, the user can continue to access the resources.

Common user identity authentication methods include user name and password login, two-dimensional code login, mobile phone SMS login, fingerprint authentication and so on.

2. The session

After a user is authenticated, the user information can be kept in the session to avoid authentication for each operation.

Session: a mechanism provided by the system to maintain the login status of current users. Common modes are session-based and token-based.

2.1 Session-based Authentication

Its interaction flow is: After user authentication is successful, user-related data generated on the server is stored in the session (current session), and the sesssion_ID sent to the client is stored in the cookie, so that the user client can verify whether the server has session data with the session_id when requesting. The client session_ID will be invalid when the user exits the system or the session expires.

2.2 Token-based Authentication:

The interaction process is as follows: After the user is authenticated successfully, the server generates a token and sends it to the client. The client can store the token in the cookie or localStorage. Each time the client requests the token, the server can confirm the user identity after receiving the token and passing the authentication.

2.3 Different Authentication Modes Based on Session and Token:

  • Storage rules are different. Session_id must be stored in the browser cookie for session-based authentication. In token-based authentication, there is no mandatory storage location for tokens.
  • The two modes have different persistence modes.
    • In session-based authentication, session information must be stored in the server memory in real time to maintain the session, which consumes server resources.
    • In token-based authentication, session information does not need to be stored. The session can be maintained through the information in the token and the token algorithm set by JWT. After receiving the token, the server will verify the validity of the user according to the algorithm generated by JWT.

3. The authorization

Also made an example of WeChat WeChat after the success of the login user can use WeChat functions, for example, a red envelope, circle of friends, add buddy, etc., there is no binding bank card users will not be able to send a red envelope, binding card user can send red packets, send red packets, send friends are WeChat function of the resources, Users can normally use the function of sending red envelopes only when they have the permission to send red envelopes, and can use the function of sending moments only when they have the permission to send moments. This process of controlling the user’s use of resources according to the user’s permission is authorization.

Why authorize?

Authentication is to ensure the legitimacy of user identity, while authorization is to divide private data in a more fine-grained way. Authorization occurs after the authentication succeeds and controls the access of different users to different resources.

Authorization: The process of user authentication controls user access to resources based on user permissions. If a user has access permission to resources, the user can access the resources normally. If the user does not have access permission, the user is denied access.

4. Authorized data model

4.1 Constitution of Authorization

How to authorize, that is, how to control user access to resources, first needs to learn the data model related to authorization.

Authorization can be simply understood as: Who has the right to perform How operations on What/which.

  • Who: refers to the Subject. A Subject generally refers to a user or a program that needs to access resources in the system.
  • What: Resources, such as system menu, page, button, code method, system commodity information, system order information, etc.
    • System functional resources: System menus, pages, buttons, and code methods are all functional resources. For a Web system, each functional resource usually corresponds to a URL.
    • System data resources: The system product information and system order information are data resources. Data resources consist of resource types and resource instances. For example, the product information is the resource type, and the product whose id is 001 is the resource instance.
  • How: Permission, which specifies a user’s Permission to operate on a resource. Permissions are meaningless without resources, such as user query permission, user add permission, call permission of a code method, modify permission of user 001, etc.Based on permissions, you can know the permissions of users on resources.
    • Function rights: Operation rights on function resources.
    • Data permission: Permission to operate data resources.

4.2 Relationship among Subjects, Resources, and Rights

Users are directly linked to permissions. If a user wants to access a resource, the corresponding permissions must be assigned to the user.

4.3 Complete data model

To facilitate the assignment of resource permissions to principals, “roles” are introduced between principals and resources. A role is a collection of permissions. For example, an administrator role includes adding, deleting, modifying, and checking products. A normal user role that includes only queries for items.

By assigning permissions to roles, when roles are assigned to principals, permissions are assigned to principals.

The complete data model is designed as follows:

The fields of each table are designed as follows:

  • Principal :(user ID, account number, password…)
  • Resources :(resource ID, resource name, access address…)
  • Permission :(permission ID, permission ID, permission name, resource ID…)
  • Role :(role ID, role name…)
  • Principal role relationship :(principal ID, role ID…)
  • Role permission relationship :(role ID, permission ID…)

4.4 Actual data model

The complete data model above is a standard data model design. In real development, resources and permissions are usually combined into one permission table.

The actual data model is designed as follows:

The fields of each table are designed as follows:

  • Principal :(user ID, account number, password…)
  • Permission :(permission ID, permission ID, permission name, resource name, resource access address…)
  • Role :(role ID, role name…)
  • Principal role relationship :(principal ID, role ID…)
  • Role permission relationship :(role ID, permission ID…)

5. RBAC

How to implement authorization? The industry typically implements authorization based on RBAC.

5.1 Role-based Access Control

RBAC role-based Access Control implements role-based authorization. For example, the principal whose Role is general manager can query salary information of all employees.

The access control flow is as follows:

According to the figure above, the authorization code is implemented as follows:

if(the main body. HasRole ("General Manager Role ID")) {query all employee information; }Copy the code

If the deputy general manager can also check the salary of all employees, then the authorization code is implemented as follows:

if(the main body. HasRole ("General Manager Role ID") | | body. HasRole ("Deputy General Manager Role ID")) {query all employee information; }Copy the code

According to the above example, the role-based access control is reflected. When requirements change, the code implementation will also change, which reflects the robustness and poor scalability.

5.2 Resource-based Access Control

RBAC provides resource-based Access Control Based on permissions. For example, an entity must have the permission to query wages of all employees.

The access control flow is as follows:

According to the figure above, the authorization code is implemented as follows:

if(the main body. HasPermission ("Query salary permission identifier")) {query all employee information; }Copy the code

If now set the deputy general manager can also check the salary of all employees, then the authorization code implementation and the above unchanged.

According to the above example, reflects the resource-based access control, in the case of demand change, code implementation will not change, reflects the robustness, scalability.

In summary, resource-based access control is more flexible than role-based access control. Therefore, resource-based access control is recommended.