How can I securely handle user logon issues in REST?

When designing a restful API that interacts with the server, you never know how to handle various issues related to user logon, such: to determine whether a user has logged on, how does one verify the communication between the server and the client for each api request to ensure that the user's authorization information is not disclosed. Simple... when designing a restful API that interacts with the App and the server, you never know how to handle various issues related to user logon, such:

• Determine whether the user has logged on
• How to verify each api request
• Ensure that user authorization information is not disclosed when the Server communicates with the client.

In short, how to design user logon?

In addition, I have designed a rest api (preferably a launched application), so I am eager to ask you for advice.
My Email: Fei2037 % # gmail.com My QQ: Feiox # % qq.com
I cannot find it. I can only ask for a teacher here ~

Reply content:

When designing a restful API that interacts with the server, you never know how to handle various issues related to user logon, such:

• Determine whether the user has logged on
• How to verify each api request
• Ensure that user authorization information is not disclosed when the Server communicates with the client.

In short, how to design user logon?

In addition, I have designed a rest api (preferably a launched application), so I am eager to ask you for advice.
My Email: Fei2037 % # gmail.com My QQ: Feiox # % qq.com
I cannot find it. I can only ask for a teacher here ~

How the API Server handles Authentication is not directly related to the design of REST.Design Principles of resource management for HTTP-based applications (Web applications)Or is a design concept that guides you how to arrange resources.

As for processing user authentication (login, etc.), it is after the REST design, which belongs to the application business logic on the server side.

In other words, no matter how you design it (whether it is REST or whether the REST is correct or not), it will not affect your business logic for processing user authentication, this is not either of them.

However, many people do not know this, and think that everything is different from the previous one if they practice REST (not to mention that most of the practices are wrong or not thorough enough, I even thought that once I use REST, everything (such as identity authentication) has only one correct path to go ...... This is a bit dumbfounded.

Let's take this question as an example for an analysis.

First, there are two authentication methods on the server: Cookie-based authentication and Token-based authentication. Which one depends on your actual situation. Cookie-based verification has a long history, and there is no need to repeat the principles and practices. In recent years, a large number of public API services have emerged, and they basically all use Token-based verification, mainly because:

1. Cross-origin Resource Sharing (CORS) Processing-although Cookie + CORS is not completely impossible, it is difficult to implement

2. Stateless-conducive to server expansion (strong scalability)

3. C/S decoupling-the server and client can be completely separated, and static resources can be processed by CDN, and the server end can be completely changed to API Service

4. CSRF Free-does not rely on cookies and does not worry about cross-origin Request Forgery (this still has doubts and remains to be verified)

...... Er, I suddenly thought it was a bit difficult. I mean you have to select a verification method first. It is obvious that Token-based authentication is a trend.

Next, assuming you have selected the Token-based authentication path, you must first understand how Token works. Simply put: the client sends the correct authentication information (such as email + password) first, and the server checks OK to generateTokenAfter the request is returned to the client, all requests of the client must containTokenThe server only needs to verifyTokenValid or not. The following figure compares Cookie-based Authentication and Token-based Authentication:

Well, according to the REST design principles, we need an Endpoint for users to request authentication and obtain tokens, such:

POST /authentication

Here, "resource" isAuthentication(According to the requirements of REST, use nouns to represent resources), usePOSTMethod To request, with the data used for authentication. The returned result depends on your business logic, but at least oneToken. Obtained by the clientTokenThen, save it (for example, to SessionStorage) and set the HEADER in the request.AuthorizationIsBearer It's done.

To sum up, the relationship between this and REST is to design an Endpoint for Token acquisition. Nothing is remarkable, and the REST is in the business logic, it depends on your needs.