The process that I applied to jwt is
Login processing -> refresh, access token issued -> Import from screen and save refresh to local storage access applies to request header
When requesting authentication -> access token verification -> If verification does not pass, re-verify by putting refresh on the error return -> screen after re-issuance of access, re-apply to the request header on the screen Re-request previously requested information
There's a problem with the authentication process In the environment I implemented, when data is retrieved, it is divided into component units, so each corresponding part sends a request separately If access does not pass the verification, it goes through a re-verification process with refresh You have to make an error on the screen or drop it to 200 to burn the branch with the error code and then go through the re-verification process with refresh, but I'm wondering if there's a more efficient way because there's a phenomenon of blinking in the middle of judging it
So what I want to ask is, I want to know how you use it with jwt. The problem I wrote above is something I have to take care of anyway, so you can ignore it
jwt
JSON Web Token is basically token. So if it's decoding well on the server side, in fact, that alone is already the basic validation. Depending on the member number or expiration date of the decoded content payload, additional processing may occur.
In that sense, you don't have to be afraid of JWT, you just have to think of the general flow of access token-based identification. The client receives a valid token during the first login process, and then hands out the token whenever it needs to be verified. If you get a response that the token is not valid, you have to go back to the login without making a meme.
The acquisition must be a member of the path of token. reissued or renewed through other channels outside the currently logged on your app is to implement token Is there a part to good manners, don't do that.Back to login to just unbeatable. And the token discrimination criteria validity instead of loosely held. (유효기간을 늘린다, 동시접속 수를 늘려준다, 토큰 안의 expire 값 대신 서버에 저장해둔 값을 이용해서 만료기간을 확인한다, expire 가 3일 이상 미래의 일이라면 토큰 갱신은 안한다 등등)
It cannot be a problem in itself that multiple requests frequently use separate tokens. If there is a problem because of that, it is not a problem with the authentication technique, but rather a mistake in its application. Think about it.
© 2024 OneMinuteCode. All rights reserved.