How can I safely handle user logon issues in REST?

When designing a restful API for an App to interact with the server, you never know how to handle various problems with user logins, such as:

• Determine if the user is logged in
• How to validate every API request
• The service side communicates with the client to ensure that user authorization information is not compromised.

In short, how do I design a user login?

Another: Children's shoes with the design of REST API (preferably on-line application), eager to ask for your advice
My email:fei2037% #gmail. com my qq:feiox#%qq.com
Can not find, only here to ask the teacher ~

Reply content:

When designing a restful API for an App to interact with the server, you never know how to handle various problems with user logins, such as:

• Determine if the user is logged in
• How to validate every API request
• The service side communicates with the client to ensure that user authorization information is not compromised.

In short, how do I design a user login?

Another: Children's shoes with the design of REST API (preferably on-line application), eager to ask for your advice
My email:fei2037% #gmail. com my qq:feiox#%qq.com
Can not find, only here to ask the teacher ~

How API Server handles authentication is not directly related to how rest is designed, rest is simply a design principle for resource management for HTTP-based applications (i.e. WEB applications) , or a way to guide you in arranging resources Design concept.

As for the handling of user authentication (login, etc.), it is after the REST design is done, belongs to the server-side application business logic.

In other words, no matter how you design (whether it is rest, or if rest is incorrect, not thorough, etc.), it does not affect the business logic that you deal with user authentication, which is not an either-or-none thing.

But many people do not know this, think that the practice of REST (not to say that most of the practice is wrong, or not thorough) everything is different from before, and even think that once you use REST, anything (such as identity authentication) has and only one right way to go ... That's a bit of a laugh.

Take this question as an example, let's do an analysis.

First, server-side authentication basically has two kinds of ways: one is based on Cookie authentication, the other is Token-based authentication. Choose which one depends on your reality. Cookie-based validation has a long history, and the principles and practices do not need to be discussed; a large number of public API services have emerged in recent years, mostly using Token-based authentication, mainly because:

1. Handle cross-domain resource sharing (CORS)--although cookie+cors is not entirely impossible, it is more difficult

2. Stateless-facilitates server-side scaling (strong scalability)

3. c/S decoupling-the server side and the client can be completely separated, so that the static resources can be processed with a CDN, the server end becomes the API Service completely

4. CSRF free--does not rely on cookies and does not worry about cross-domain forged request attacks (this is still questionable)

...... Well, suddenly it's a little off-topic, I mean you have to choose a verification method first, obviously Token-based authentication is a trend.

Next, assuming you chose the path based on token authentication, you first have to figure out how token is played. Simply put: The client first sends the correct authentication information (such as e-mail + password), the server-side check OK after the generation of a token returned to the client, and then all the client's request to include this token, the server side only need to verify the Token is valid. Here is a picture, contrasted with cookie-based authtication and token-based authentication, very good:

Well, according to the REST design principle, we need a Endpoint for the user to request authentication and get tokens, like this:

POST /authentication

Here, "resource" is authentication (according to REST requirements, use nouns to represent resources), use POST method to request, with data for authentication information, return results to see your business logic, but at least have a token. After the client gets token , save it (for example, in Sessionstorage), set the value of the HEADER in the request Authorization Bearer , and finish.

To sum up, the relationship between this and REST is to design a Endpoint to get tokens, nothing great, the rest of the business logic, how to write depends on your needs.

