In the previous two articles “Java Authority framework 1 – Business Pain points and Technology Research”, “Java Authority Framework 2 – Sureness Framework introduction”, focus on the introduction of the Java Web system in the design of authority, but I feel that this series is not very general, it is difficult to continue to go further.

That’s why I’m writing a new column called Web Development, which will share some of my insights from web development, including permission system design, Django hands-on, common Web technologies, front-end knowledge, and more. Today, we will continue to discuss the permission design, and explain the various technical knowledge points that are often used.

Authentication and Authorization

Authentication and authorization are the two cornerstones of permission design. No permission framework can escape these two cornerstones.

For example, shiro framework:

Shiro explains both:

Authentication: Sometimes referred to as’ login ‘, this is the act of proving a user is who they say they are.

Authorization: The process of access control, i.e. determining ‘who’ has access to ‘what’.

In a nutshell, the difference between them is:

Authentication: Who you are. The system does identity/user authentication.

Authorization: What do you have the authority to do? The system already knows who you are, but it also depends on whether you have specific access to specific resources.

RBAC model

RBAC is the most commonly used access control model for system permission control.

RBAC is role-based Access Control. This is a way to associate permissions with roles, and roles are also associated with user permissions.

In RBAC, permissions are associated with roles, and users gain permissions for those roles by becoming a member of the appropriate roles. This greatly simplifies permission management.

The most classic database implementation of RBAC is the five-table design, which consists of three real tables (users, roles, and permissions) plus two relational tables (user-role, role-permissions, both many-to-many relationships).

Let me also talk about my understanding of permission tables. In fact, the permission control of a Web system can be divided into many dimensions. If the project is separated from the front and back end, the granularity of the back-end API needs to be controlled, as well as the granularity of the menu or button that can be displayed in the front end.

Apis, menus, and buttons can be viewed as resources, and they can be placed together in the permission table, separated by fields, or separated, but the same thing is many-to-many association with permissions through roles.

I recommend a project here, github.com/tomsun28/bo…

This provides a demo environment: http://47.110.55.246/, which is the most consistent with the authority design model of the front-end page design I have seen so far.

The cookie and session

Cookies and sessions are both used to track the identity of a browser user, but they are used in different scenarios.

Cookies are stored on clients to save user information. Typical scenarios are as follows:

  • We save the user information that has logged in in the Cookie, and the page will automatically fill in some basic information for you when you visit the website next time. In addition, cookies can store user preferences, themes, and other Settings.
  • A Cookie is used to save the Session or Token. The Cookie is carried when the request is sent to the backend, so that the backend can obtain the Session or Token. This keeps track of the user’s current state, since the HTTP protocol is stateless.
  • Cookies can also be used to record and analyze user behavior. To take a simple example, when you shop online, HTTP protocol is stateless. If the server wants to obtain the status of your stay on a page or what products you have viewed, a common way to do this is to store this information in cookies

The main function of a Session is to record user status through the server. After creating a specific Session for a specific user, the server can identify the user and track the user.

Cookie data is stored on the client (browser) and Session data is stored on the server. Session security is relatively higher. If some sensitive information about the Cookie is not written into the Cookie, it is best to encrypt the Cookie information and then decrypt it on the server when it is used.

In addition, it is important to note that sessions cannot exist without cookies. Generally, Session ids are stored by cookies. If you use cookies to store Session ids, if the client disables cookies, So the Session doesn’t work. However, it is not necessary to use a Session without cookies. For example, you can put the SessionID in the requested URL baidu.com/?Session_id… . This scheme is feasible, but the security and user experience is reduced.

In production practice, servers are deployed horizontally to multiple nodes, and we typically use a single data node (such as the Redis cache, which I’ll discuss in the Distributed column) that all servers can access to store Cookie or Session information. To ensure high availability, data nodes should avoid being single points.

In addition, I would like to share another development experience. I was once in charge of a project, which used session to save user information. I needed to access the data of this system by using codes. Change tomcat session-config to httpOnly false. This is a security violation, as you can see in my article “Development Challenges for Unknown Systems”.

Common Login Schemes

In this section, I’ll introduce some common login schemes.

JWT

In the previous discussion, we need to save the login information of Cookie or Session on the server side. Here we introduce a way to save the login information on the client side using Token. JWT (JSON Web Token) is implemented in this way. In this way, the server does not need to save Session data, but only saves the tokens returned by the server to the client, which improves scalability.

JWT is essentially a signed piece of JSON-formatted data. Since it is signed, the recipient can verify its authenticity.

JWT consists of three parts:

  • Header: Describes the metadata of the JWT, defining the algorithm for generating the signature and the type of Token.
  • Payload: Stores the data that needs to be transmitted
  • Signature: The server generates the Signature algorithm specified in the Header (HMAC SHA256 by default) using Payload, Header, and secret.

In token-based authentication applications, the server creates a Token using Payload, Header, and a secret and sends the Token to the client. The client saves the Token in a Cookie or localStorage. All subsequent requests from the client carry the Token. You can put it in a Cookie and send it automatically, but that’s not cross-domain, so it’s better to put it in the HTTP Header Authorization field: Bearer Token.

The detailed process is as follows:

  • A user sends a user name and password to the server to log in to the system.
  • The authentication service responds and returns the signed JWT, which contains information about who the user is.
  • Each subsequent request from the user to the backend will include JWT in the Header.
  • The server checks the JWT and retrieves user-related information from it.

Reference: JWT. IO /

SSO

SSO(Single Sign On) means that a user logs in to one of multiple subsystems and has access to other systems related to it. For example, after we landed on Baidu, we can also log in to Baidu web disk, Baidu post bar and so on.

Single sign-on is very common, and I’ve done a lot of internal system development in companies that involve single sign-on.

Single sign-on has the following benefits:

  • User perspective: users can log in and use multiple times, no need to record multiple sets of user names and passwords, save worry.
  • System administrator point of view: administrators only need to maintain a unified account center on it, convenient.
  • New system development perspective: new system development only need to directly connect to the unified account center, simplify the development process, save time.

The 2.0

OAuth is an industry-standard authorization protocol that allows third-party services to obtain their own resource information through authorization without informing third parties of their account passwords.

In fact, it is a kind of authorization mechanism, and its ultimate purpose is to issue a time-sensitive Token to the third party application, so that the third party application can obtain relevant resources through this Token.

A common scenario of OAuth 2.0 is third-party login. When your website is connected to third-party login, it usually uses the OAuth 2.0 protocol.

I have used the enterprise wechat login in the project, which is also a login method of OAuth2.0. Please refer to the official documents of wechat:

  • Work.weixin.qq.com/api/doc/900…
  • Qydev.weixin.qq.com/wiki/index….

The following is a brief description of the most classic Authorization Code mode in OAuth2. The flow is as follows:

In the flowchart, there are four roles.

  • ResourceOwner indicates the ResourceOwner, that is, the user
  • User-agent is a browser
  • AuthorizationServer is an authentication server, which can be understood as the user resource custodian, such as the enterprise wechat server
  • Client is a third-party service

The call flow is as follows:

  1. The user accesses a third-party service, which directs the user to the authorization page of the authentication server by constructing an OAuth2 link, with parameters including the identity ID of the current third-party service, as well as the redirected URI
  2. The user chooses whether to authorize or not
  3. If the user agrees to authorize, the authentication server redirects the user to the redirection URI specified in the first step, along with an authorization code.
  4. After receiving the authorization code, the third-party service carries the redirection URI from the authorization code and applies for a certificate from the authentication server.
  5. The authentication server checks the validity of the authorization code and the redirection URI and issues AccessToken upon passing.

(The calls of 3 and 4 are background calls, not through the browser)

During actual development, you can refer to the cache suggestions provided by wechat officials to avoid frequent requests to the wechat server.

Caching solution recommendation: There is a time cost to obtaining membership through the OAuth2.0 authentication interface. You are advised to use the following solution for frequently obtaining membership:

  1. The URL in the enterprise application directly fills in the enterprise’s own page address
  2. When the member operation switches to the enterprise page, the enterprise background checks whether there is a cookie that identifies the member. The cookie is generated by the enterprise
  3. If there is no matching cookie, it is redirected to the OAuth authentication link to obtain the member’s identity information, and the enterprise background implants the cookie information identifying the member’s identity
  4. After obtaining the membership according to the cookie, enter the corresponding page