php - Restful checkout and login status persistence

Question

I won’t discuss oauth here for now, I want to understand jwt first

I don’t understand these two concepts very well: verification and login retention

I currently give the android and ios clients a key secret, and then my server also uses this secret

Then the client’s parameters such as timestamp, nonce, etc. are matched with the key I gave them. Multiple parameters are encrypted into one parameter sign

is then passed to the server together, and then the server encrypts the first few parameters plus the server's password, and finally determines whether it is equal to the last parameter sign

sent by the client.

But I now think that the above verification I did seems to only prove that the client of this request knows the secret key of my server, which means that this request is allowed by my server

But I still don’t know whether the user has logged in, so I asked the client to add a parameter token to me. If the user requests the login interface and logs in successfully, I will save the session to redis for one month, and then Return token=sessionid, let it be stored in the client, and bring it to me next time. If I get it and can find this session in redis, it will prove that he is logged in

Also, someone online said that this is a custom jwt, right?
I don’t know what is the biggest difference between what I did and jwt

For example, my method relies on sessionid to determine the user's login status. The server stores the session

Jwt I read the information for a while and it seems that after issuing the token to the client, the server does not seem to save the token. Then after the client parameters arrive, it seems that it is just the first step of my own method ( Is it equal to sign after encrypting multiple parameters and keys?) But a lot of information seems to say that this can already prove login. If this is the case, is my method redundant and using session to determine whether to log in?

Answer 1

https://jwt.io/

One of the characteristics of JWT is that it is stateless and there is no concept of login.

Originally, the so-called login is only a concept understood by humans, and the server does not have this concept. What is login? Only with authorized access (content that can only be accessed after logging in).

Answer 2

jwt does not need to store the token on the server side, because the token contains the issuer, user, signature and other information, which is enough to prove the login and has not been tampered with. Because once tampered with, the signature cannot be verified. As for sessionid, it is different. Session is mainly used to store some other data on the server side. These data may be sensitive and inconvenient to put in jwt. Of course, session is just a type of storage. You can also store it in redis or even other types of storage systems. In fact, you can also think of cookies as tokens (although this is wrong, but it will be better understood this way), and session is just one of the values, nothing more.