if both SessionID and Token are stored in redis so that multiple servers can share
, does that make any difference?
about whether there is a state or not and whether restful
they all need to save information on the server, I think it is stateful
Why do some say that Token is stateless and restful, while Cookie/SessionID is not?
A lot of people use token, in the session way, so they think the two are the same.
session thinking is like this: pass sessionID or so-called token to the server, and then the server finds the user data according to this key value, maybe in the session file, maybe in the redis, and then reads the data inside the uid=1, so that the user identity is established.
and the real token thinking is like this: uid=1 is stored directly on the client, of course, it will not only retain such simple data, it is easy to forge. The actual saved data may be like this uid=1 | 6166b2002fdcb5df. The latter part of the signature is encrypted based on the first part of the data, and the encryption algorithm is known only to the server, so you cannot forge the data. After the server obtains the token, it verifies the signature of the first part of the data, compares it with the second part, and if it is consistent, directly establishes the user identity uid=1. The whole operation is operated directly in memory and does not need to read the session file or redis. You can even save the entire user information uid=1&nickname=xxx&money=1000 to token.
for example, the commonly used JWT, is used. It is divided into three parts, each of which is re-base64_encode, but the idea is the same.
Where is the source of the problem? Who said that? To express doubt. Is there something about token in the definition of
RESTful?
as far as I understand, both token and session just identify the source of the request and which user requested it.
in other words, the api implementation of the website, I can clearly use session, why should there be token? It's unnecessary.
whether token or session_id is similar in principle, token is usually placed on the interface to request directly, and token is usually placed in header to make the request. In any case, the front and back end need to initiate data interaction. It doesn't matter whether you use token or session, as long as it can be implemented.
you can see that the jwt token, does not need to exist on the server. All authentication information (user id, expiration time, etc.) is encrypted in the token. You can obtain the authentication information by decrypting the token on the server, unlike session, which needs to retrieve the status according to the cookie at the server.
as for security, jwt+https is basically very secure. Another advantage of this kind of stateless token is that it can be expanded painlessly, because session files are stored on disk. When you have a second server, you have to transfer session files to redis or other media in order to share and log in. Jwt itself comes with all the authentication information and uses
directly.although I am not a great god, I can introduce a great god
Token certification context codeshelper.com/a/1190000013010835 by Border Town
if we attach all the state information to the Token, the server can not save it. But the server still needs to verify that the Token is valid. However, as long as the server can confirm that it is a self-signed Token, and its information has not been changed, then the Token can be considered valid-the "signature" can guarantee this. It is often said that signatures are signed by one party and verified by the other party, so asymmetric encryption algorithm should be used. But here, the signing and verification are on the same side, so the symmetric encryption algorithm can meet the requirements, while the symmetric algorithm is much faster than the asymmetric algorithm (up to tens of times the gap). To take it a step further, symmetric encryption algorithms have the ability to restore encrypted content in addition to encryption, which is not necessary when signing Token-since there is no need for decryption, the digest (hash) algorithm is faster. You can specify a hash algorithm for the password, which is, of course, HMAC.
RESTful is defined as stateless, and token is more consistent with this. Each request passes the parameter token , a stateless interaction.
and we all know that http is stateless, so every time we have to take the state to request the server, that is, Cookie/SessionID , the cookie mechanism adopts the scheme of keeping the state on the client side, while the session mechanism adopts the scheme of keeping the state on the server side.