need help learning jwt
I am currently learning jwt authentication and i have a few questions
1) I know its almost impossible for jwt to generate to identical tokens given how long the token is but what if there is this 1 in a million chance where 2 identical tokens are generated? Does jwt cross check whether a certain token has been generated before and whether the current jwt token is unique?
edit : i just remember that jwt token is based on username + salt + time, so am i right to say that as long as username is different + salt to prevent other people from generating the same token + not generated on the same second there will never be 2 identical token?
2) is there a reason to store the tokens in db? in PHP session ids are stored in a table for a variety of reasons i wonder if jwt token is the same as session IDs.
3) I notice in some projects they generate the access token to last only for 15 seconds, then generate a refresh token. What is the purpose of doing that? What is the advantage of using refresh tokens instead of access tokens?
4) I noticed that some projects store the tokens in local/session storage in client side and i read that its not safe to do so and yet people still do it. Is it bad practice?
5) Is there a way to expire jwt tokens only after a period of inactivity? I dont want to set a time frame for its expiration rather only after a period of time of inactivity.
1) I know its almost impossible for jwt to generate to identical tokens given how long the token is but what if there is this 1 in a million chance where 2 identical tokens are generated? Does jwt cross check whether a certain token has been generated before and whether the current jwt token is unique?
edit : i just remember that jwt token is based on username + salt + time, so am i right to say that as long as username is different + salt to prevent other people from generating the same token + not generated on the same second there will never be 2 identical token?
2) is there a reason to store the tokens in db? in PHP session ids are stored in a table for a variety of reasons i wonder if jwt token is the same as session IDs.
3) I notice in some projects they generate the access token to last only for 15 seconds, then generate a refresh token. What is the purpose of doing that? What is the advantage of using refresh tokens instead of access tokens?
4) I noticed that some projects store the tokens in local/session storage in client side and i read that its not safe to do so and yet people still do it. Is it bad practice?
5) Is there a way to expire jwt tokens only after a period of inactivity? I dont want to set a time frame for its expiration rather only after a period of time of inactivity.
(edited 2 years ago)
I can answer some of these having a limited amount of experience with JWT.
3. The point of generating a refresh token every X seconds/minute is to primarily limit the time a hacker/unauthorised individual has access to the system. Even if they acquire the token they only have it for a limited amount of time before it becomes worthless. Tokens I’ve used in the past tend to have a 5 minute expiration time,.
4. Ive not personally ever stored the token in local storage in the browser, for me it’s always been stored somewhere in the code. I can’t imagine it’s necessarily the best practise to store it in the browser, but only an authorised user will ever have it in local storage - and once they’ve finished it’ll be removed.
5. JWT has an expiration timer - if you wanted to expire the token after a period of inactivity you’d be able to do this through the code by either wiping the token, or by not going to get a refresh - this would result in 401.
3. The point of generating a refresh token every X seconds/minute is to primarily limit the time a hacker/unauthorised individual has access to the system. Even if they acquire the token they only have it for a limited amount of time before it becomes worthless. Tokens I’ve used in the past tend to have a 5 minute expiration time,.
4. Ive not personally ever stored the token in local storage in the browser, for me it’s always been stored somewhere in the code. I can’t imagine it’s necessarily the best practise to store it in the browser, but only an authorised user will ever have it in local storage - and once they’ve finished it’ll be removed.
5. JWT has an expiration timer - if you wanted to expire the token after a period of inactivity you’d be able to do this through the code by either wiping the token, or by not going to get a refresh - this would result in 401.
Original post by Strange5050
I can answer some of these having a limited amount of experience with JWT.
3. The point of generating a refresh token every X seconds/minute is to primarily limit the time a hacker/unauthorised individual has access to the system. Even if they acquire the token they only have it for a limited amount of time before it becomes worthless. Tokens I’ve used in the past tend to have a 5 minute expiration time,.
4. Ive not personally ever stored the token in local storage in the browser, for me it’s always been stored somewhere in the code. I can’t imagine it’s necessarily the best practise to store it in the browser, but only an authorised user will ever have it in local storage - and once they’ve finished it’ll be removed.
5. JWT has an expiration timer - if you wanted to expire the token after a period of inactivity you’d be able to do this through the code by either wiping the token, or by not going to get a refresh - this would result in 401.
3. The point of generating a refresh token every X seconds/minute is to primarily limit the time a hacker/unauthorised individual has access to the system. Even if they acquire the token they only have it for a limited amount of time before it becomes worthless. Tokens I’ve used in the past tend to have a 5 minute expiration time,.
4. Ive not personally ever stored the token in local storage in the browser, for me it’s always been stored somewhere in the code. I can’t imagine it’s necessarily the best practise to store it in the browser, but only an authorised user will ever have it in local storage - and once they’ve finished it’ll be removed.
5. JWT has an expiration timer - if you wanted to expire the token after a period of inactivity you’d be able to do this through the code by either wiping the token, or by not going to get a refresh - this would result in 401.
So, the concept is when i log in ,server generate a token, give it to client side, client store it as cookies or in local/session storage, then as long as client have that token and its not expired , it will be passed in the http header and sent to the server for verify on every http request , and that saves the client from having to login at every turn. And the server will check the token and verify it at the start of every page and every http request, if its invalid then it will kick the user back to login page, and if the user log out prematurely (before token expiration time) the token is removed from client side and added to a black list on the server side.
Am i right?
Original post by HucktheForde
So, the concept is when i log in ,server generate a token, give it to client side, client store it as cookies or in local/session storage, then as long as client have that token and its not expired , it will be passed in the http header and sent to the server for verify on every http request , and that saves the client from having to login at every turn. And the server will check the token and verify it at the start of every page and every http request, if its invalid then it will kick the user back to login page, and if the user log out prematurely (before token expiration time) the token is removed from client side and added to a black list on the server side.
Am i right?
Am i right?
Yes. The server will generate you a token that consists of various pieces of information (if you're curious grab a token and decode it here: https://jwt.io/). Now you've got this token, for the duration in which it hasn't expired, you're now authorised. Every request you make to the server will contain this token in the headers as you said. If/when the token expires - and you make a request to the server, you will more than likely be faced with a HTTP 401 unauthroised error. If this is the case, then in terms of the app/front-end it's then up to you to kick the user back to the login page (or if your application goes off to another domain to be authenticated - for it then to redirect you to the login page). If the user logs out then yes, the token is removed from the client-side.
Original post by Strange5050
Yes. The server will generate you a token that consists of various pieces of information (if you're curious grab a token and decode it here: https://jwt.io/). Now you've got this token, for the duration in which it hasn't expired, you're now authorised. Every request you make to the server will contain this token in the headers as you said. If/when the token expires - and you make a request to the server, you will more than likely be faced with a HTTP 401 unauthroised error. If this is the case, then in terms of the app/front-end it's then up to you to kick the user back to the login page (or if your application goes off to another domain to be authenticated - for it then to redirect you to the login page). If the user logs out then yes, the token is removed from the client-side.
hopefully i have not annoyed you... what is the difference between access token and refresh token and why do we need 2? they are both generated the same way!
(edited 2 years ago)
Original post by HucktheForde
hopefully i have not annoyed you... what is the difference between access token and refresh token and why do we need 2? they are both generated the same way!
It's alright
Refresh tokens carry the information necessary to get a new access token. In other words, whenever an access token is required to access a specific resource, a client may use a refresh token to get a new access token issued by the authentication server. Common use cases include getting new access tokens after old ones have expired, or getting access to a new resource for the first time.A pretty good source: https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/
Quick Reply
Related discussions
- How do you learn python at a gcse level?
- does tuition make a difference in gcse
- Gcse languages
- Theoretical perspectives on reflection to professional development
- psychology at Loughborough
- how do i revise?
- A-level Latin
- AQA Politics revision help!
- Evaluation points OCR psychology
- Is there an actual point in sitting A level exams
- How do you get from a 2:2 to a first class degree?
- Moving to CloudLearn
- People that took a gap year before university
- DofE
- 6 ways to learn at university
- Clinical psychology question
- How many quotes? Eng Lit GCSE
- help
- what is a valid reason for changing course
- Software engineering degree apprenticeship.
Latest
Trending
Last reply 1 month ago
Free website hosting providers with no strings attached?Posted 3 months ago
iDEA silver citizen badge three. Milkshake shack coding problem.Last reply 4 months ago
How do you practice programming java for beginners?Last reply 8 months ago
hows the employment market for tech work in the UK?Trending
Last reply 1 month ago
Free website hosting providers with no strings attached?Posted 3 months ago
iDEA silver citizen badge three. Milkshake shack coding problem.Last reply 4 months ago
How do you practice programming java for beginners?Last reply 8 months ago
hows the employment market for tech work in the UK?
