disagree with the statement on floor 3 that clients do not need expiration time.
the server should make the final decision on token, but it is also necessary for the receptionist to know the expiration time. You can take a look at my token handling method:
: SQL/REDIS(IO) userid,token,expire,scope?
// expire
, expire0 () ,Redis
: userid,token,expire | tokens:{scope1:{token:'...',expire:150000000},scope2:{...}...}
// scpoe()
needless to say on the server side, expire determines whether token is valid
and the most important thing for the client is to have a temporary check. The most commonly used scenario is the long-term residence of login on the mobile end. For example:
We have set a maximum valid time of 30 days, and our user active frequency is 7 days.
then the front desk can check the token according to the weekly (flexible setting) advance. If it takes 7pm and 30 days, We request to refresh the token at the front desk so that users can log in securely if they do not log in forever. Of course, if you haven't logged in for more than 30 days, then the token expires and you won't be able to update and need to log in manually.
_ _ RE: third-party token Management
when it comes to third-party token, you just need to understand your own server as if it were a client. The logic is the same, but there must be scope. Take Wechat authorized login as an example, when we get the token, we will also get the expires (valid duration). Then we need to store it as a timestamp time (true) + expires*0.9 on our server so that we can re-request before the token expires. Logically consistent with the client temporary inspection above, the implementation is slightly different taking into account different business requirements.
There is no need to store expiration time in
token. When to expire is determined by the token stored on the server: the token on the server is generally stored in an in-memory database like Redis, and the expiration is controlled by Redis.
when the client sends the service token, the server will go to the redis to check whether the key exists (the expiration will be automatically deleted), thus implementing the expiration mechanism of token. By the way, single sign-on can also be achieved in this way.
there are similar articles php JWT on the web
token can be encrypted in decryptable mode
data is stored as:
[
'user_id' => 1,
'create_time' => 152378273,
]
Token
specific case: http://www.simengphp.com/inde.
