but I feel that as long as this token can be brought to the client, it will be dangerous, so for the sake of security after separation, I prefer the following solutions

1. After the front and rear ends are separated, the front end uses nginx as the server and reverse proxies to the back-end interface. Note that here you reverse proxy to the private network IP+ port of the back-end server, and turn off the public network mapping of the back-end domain name
2. After receiving the request on the interface server, you can check the ip link of X_forward_for to see if the middle proxy IP belongs to your own nginx server. Add a whitelist
3. If you really need to open the public network mapping to do some functions such as authorization and payment, the nginx layer still keeps the private network ip forwarding and adds the whitelist of domain name access, including domain name and ip

that's about it. ~

the token interface provided by the token backend is used to verify user information.
does not mean that I will give you a token
token information after a get request. It can include your client source basic user information expiration time

token is generally returned after logging in, and the front end is responsible for storing it. The next ajax request will bring this token , and the backend verifies the validity of the token . If it passes, it continues. If it fails, it returns a status code with an invalid token . The frontend automatically jumps to the login page based on the status code.

1. AJAX requests / login interface, POST the user name and password, and PHP generates a token for the user and returns it to the front end.
The
2. front end saves token in the browser localStorage .
The
3. frontend determines that all requests except login take token , which can be sent through the Authentication header in header .
4. PHP can identify the user and perform the operation if it verifies that token is valid.
5. if the PHP side finds token invalid, you can return a 401 error to the front end, and JS directs the user to the login page

what you said token is useless, as long as it is exposed on the client, you can restrict REFERER and the domain names that allow cross-domain

to determine the source of the request? I don't quite understand, ah, whether the port is different, for example: PC mobile or different pages
request price parameters? what does type 1 represent? what does the backend represent? what does the backend get type to judge?

the front end does login authentication, and the back end can do time tokens

on the other hand, the token obtained based on user authorization (that is, the user is required to fill in the account password) is trusted.

Front-end requests can basically be forged, so they are not absolutely trusted.

except for the authentication and authentication of the requested user.
request with csrf token, backend authentication,
set Access-Control-Allow-Origin,
backend disable public network mapping, and if necessary, you can also put it on the ip whitelist
. It is safe enough for comprehensive use.

determine the source of the request.
you can design an interface to unify a header or get post parameter type.
for example: type=h5 is h5, type=android is Android, and ios
, or you token with type such as xxxtoken,token=h5, the backend comes to get token for verification, and the type is the source you want