In our Java business system, permissions, authentication, and similar concepts are more or less involved. But many small partners are still silly to distinguish these concepts and differences, today we will have a good stroke, the concept of the difference is deeply engraved in my mind.

Certification Authentication

Authentication. In.NET Framework security, the process of discovering and verifying the identity of a subject by checking the user’s credentials against those of some organization.

Of course, today’s discussion will not use such blunt words to explain.

  • In layman’s terms, it means to verify the current user’s identity and prove that “you are yourself” (for example, when you clock in and out every day, you need to clock in with your fingerprint, and when your fingerprint matches the fingerprint entered in the system, you clock in successfully).

Common authentication methods:

  1. User name and password for login
  2. Email sends the login link
  3. Mobile phone number Receiving verification code
  4. As long as you receive the email/verification code, you are the account owner by default

Authorization Authorization

The so-called authorization is that a user grants other applications the permission to access certain resources of the user.

For example, when you install an APP on your phone, the APP will definitely pop up asking if you can grant permissions (access to albums, locations, etc.). When you access the wechat mini program, when you log in, the mini program will ask whether you are allowed to grant permissions (to obtain personal information such as nickname, avatar, region and gender).

The authorization modes are cookie, session, Token, and OAuth

Certificate Credentials

The premise of authentication and authorization is the need for a medium (certificate) to mark the identity of the visitor.

This is very good understanding actually, id card everybody affirmation is all have. Through the ID card, we can apply for mobile card/bank card/personal loan/transportation and so on, which is the certificate of certification.

In the Internet application, the general website will have two modes, tourist mode and login mode.

  • In tourist mode, you can browse articles on the website normally. Once you want to like/favorite/share an article, you need to log in or register an account.
  • In login mode, when a user logs in successfully, the server issues a token to the browser that the user is using. This token is used to identify the user. Every time the browser sends a request, the user can use the functions that cannot be used in tourist mode.

Cookie

HTTP is a stateless protocol (for the transaction without memory, each time the client and the server session is complete, the server will not save any session information) : each request is completely independent, the server can’t confirm the identity of visitors to the current information, unable to distinguish between the last request of the sender and the sender is not the same person at this time.

So in order for the server and browser to do session tracking (to know who is visiting me), they must actively maintain a state that tells the server whether the previous two requests came from the same browser. This state needs to be implemented through cookies or sessions.

Cookie stored on the client: A cookie is a small piece of data that the server sends to the user’s browser and keeps locally. It is carried and sent to the server the next time the browser makes a request to the same server.

Cookies are not cross-domain: each cookie is bound to a single domain name and cannot be used under other domain names. First-level domain names and second-level domain names are allowed to be shared (depending on domain).

Session

Session is another mechanism to record the session status between the server and the client. Generally, the session is implemented based on cookies. The session is stored on the server, and the session ID is stored in the cookie of the client

The picture

Session authentication process:

  1. When a user requests the server for the first time, the server creates a Session based on the information submitted by the user
  2. The Session id is returned to the browser when the request is returned
  3. After receiving the SessionID information from the server, the browser stores the information in the Cookie, and the Cookie records the domain name of the SessionID
  4. When the user accesses the server for the second time, the request will automatically determine whether there is Cookie information under the domain name. If there is Cookie information, the server will automatically send the Cookie information to the server, and the server will obtain the SessionID from the Cookie. If the Session id is not found, the user is not logged in or the login is invalid. If the Session id is found, the user is logged in and you can perform the following operations.

At present, most systems verify user login status according to this principle.

The difference between cookies and sessions

This is one of the most frequently asked interview questions.

  1. Security: The Session is more secure than the Cookie. The Session is stored on the server and the Cookie is stored on the client.
  2. The value types are different: Cookies only support string data. If you want to set other types of data, you need to convert them into strings. Session can store any data type.
  3. Different validity periods: Cookies can be set to hold for a long time. For example, the default login function that we often use, the Session usually expires for a short time, and the client shuts down (by default) or the Session times out will be invalid.
  4. Different storage sizes: The data stored by a single Cookie cannot exceed 4K, and the data stored by a Session is much higher than that stored by cookies. However, if there are too many visits, too many server resources will be occupied.

The Token Token

Acesss Token A resource certificate used to access a resource interface (API). Uid (unique user identification), time(timestamp of the current time), sign (signature, Acesss Token is characterized by stateless server and good scalability. It supports mobile devices. It is secure and supports cross-program invocation of token.

The picture

  1. The client requests login using the username and password
  2. The server receives a request to verify the user name and password
  3. After the authentication succeeds, the server issues a token and sends the token to the client
  4. After receiving the token, the client stores it, for example, in a cookie or localStorage
  5. Each time a client requests resources from the server, it must carry a token signed by the server
  6. The server receives the request and verifies the token in the request. If the verification succeeds, it returns the requested data to the client

Refresh Token The Refresh Token is dedicated to refreshing access tokens. If you do not have refresh token, you can refresh the Access token, but each refresh requires the user to enter the login user name and password, which can be troublesome. With the refresh token, this hassle can be reduced. The client directly uses the Refresh token to update the Access token without additional operations by the user.

The picture

The Access Token has a short validity period. When the Acesss Token becomes invalid, the user can obtain a new Token by using the Refresh Token. If the Refresh Token also becomes invalid, the user can only log in again. The Refresh Token and expiration time are stored in the server database and verified only when a new Acesss Token is applied for. It does not affect the service interface response time and does not need to be kept in memory to handle a large number of requests like the Session.

The difference between Token and Session

Session is a mechanism for recording the Session status between the server and the client. The server is stateful and can record Session information. Tokens are tokens, resource credentials needed to access resource interfaces (apis). Token makes the server stateless and does not store session information.

Session and Token are not contradictory. As an authentication Token, Session security is better than Session security, because each request has a signature and can prevent listening and replay attacks, while Session must rely on the link layer to ensure communication security. If you need to implement stateful sessions, you can still add sessions to store some state on the server side.

Session authentication is simply storing User information in the Session. Because of the unpredictability of the SessionID, it is considered safe for the time being. Tokens, if referred to as OAuth tokens or similar mechanisms, provide authentication and authorization, authentication for the user and authorization for the App. The goal is to give an App access to a user’s information. The Token here is unique. It cannot be transferred to other apps, nor can it be transferred to other users. Session provides only a simple authentication, that is, as long as the SessionID is present, the User is considered to have full rights. This data should only be kept on the site and should not be shared with other websites or third-party apps.

So to put it simply: If your user data may need to be shared with a third party, or allow a third party to call an API, use Token. If it’s always just your own website, your own App, it doesn’t matter what you use.

JWT – JSON Web Token

JSON Web Token (JWT) is currently the most popular cross-domain authentication solution

JWT is an open jSON-based standard (RFC 7519) implemented for passing declarations between network application environments. JWT declarations are typically used to pass authenticated user identity information between the identity provider and the service provider to facilitate resource retrieval from the resource server. For example, for user login.

JWT can be signed using either the HMAC algorithm or RSA’s public/private key. These messages are trusted because of digital signatures.

The picture

JWT certification process:

  1. After a user enters the user name and password to log in, the server returns a JWT to the client after successful authentication
  2. The client saves the token locally (usually using localstorage, but can also use cookies)
  3. When a user wishes to access a protected route or resource, the JWT needs to be added using Bearer mode in the Authorization field of the request header