Timeline for JWT refresh token exponentially?
Current License: CC BY-SA 3.0
5 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jul 30, 2016 at 18:54 | comment | added | Jack | JWTs can contain claims, which you can use to make different kinds. Your long lived JWTs are simply those which claim they're long lived in the payload. It's up to whatever auth service you're using/creating to generate long lived tokens with that claim. When attempting to refresh tokens, the auth service should verify that the token you're using to authenticate has that claim. | |
Jul 30, 2016 at 11:39 | comment | added | momokjaaaaa | how would you implement this specifically in JWT? The long lived and short lived ones. I see them both as the same. If I don't have short lived tokens, I can still refresh using the long lived ones since the long lived ones will generate new tokens valid for 15 minutes.. "Clients would only ever send their long lived tokens to that auth service, minimizing the possibility of network eavesdroppers stealing the token." Why don't just send the short lived tokens to the auth service to refresh it? | |
Jul 30, 2016 at 11:20 | vote | accept | momokjaaaaa | ||
Jul 30, 2016 at 11:25 | |||||
Jul 13, 2016 at 16:55 | history | edited | Jack | CC BY-SA 3.0 |
deleted 12 characters in body
|
Jul 13, 2016 at 16:28 | history | answered | Jack | CC BY-SA 3.0 |