I think so too.

cookie-based authentication has cross-security problems, either automatically or manually, but token passes the token to other domains after several redirects with the certification center. The subject can refer to the authentication process of sso, and the authentication process of oath is about the same.

I don't know if you mean CSRF by cross-domain security.

if so, find out what happened to csrf first:

1. user logs in to website A normally and generates sessionid or token
2. the user visited the malicious site Bli B while not quitting A, and secretly accessed An as a "user" in a way similar to .

Let's take a look at the problem again:

1. as soon as you log in, you get the login credentials (sessionid or token), which you will pass back to the server on your next visit, so you need to "save" on the client.
2. traditionally, sessionid is placed on cookie, so that the browser will "automatically bring it" the next time you visit, but it is not "necessary". After you understand the principle of session, sessionid can also be placed in header (or even get parameters or post parameters), but in this way, the browser will not automatically bring it, you need to send it manually, which is the same reason as token in header.
For the problem of
3. postback, hide the call through src. The browser automatically carries cookie by default, but it doesn't seem to be carried by default through ajax call (I don't confirm that I write less frontend)

therefore, putting cookie in token actually has two meanings: one is to store it in the client cookie, and the other is the definition (transmission mode) in the authentication protocol. For example, if you put the token into the cookie, but the server still recognizes the token in the header, it is useless to bring the token automatically in the cookie when you request it.