Refresh Token Client Side

[psychok7]

This might be somehow related to #92 but i felt that it deserved a new issue.

While reading the official documentation on Refresh Tokens, i found this bit Each time the user loads the page, you can check if there is an existing non-expired token and if it's close to being expired, refresh it to extend their session.

The thing is, i want my API to support both Web and Mobile, for my Web part i am using jQuery to ask for the refresh tokens. The thing is how can i do this part and if it's close to being expired, refresh it to extend their session without passing my Django secret key to the template so that i can decode the token in my local storage and figure out when it is going to expire before making an unnecessary request??

If i should not decode the token, then for every page load i would have to make an additional request to ask if my current token has not expired yet? That seems a bit overkill to me and it is whats causing me to be confused about it.

What is the correct approach here??

Thanks

[cbouvier15]

I think you don't (shouldn't) need to pass the Django's secret key to the front-end in order to decode the token and obtain the expiration time.

For example, this library created for auth0 to work with Json Web Tokens in AngularJS, performs methods to decode the token, verify it's expiration time, and so on, without using Secret Key.

Maybe you can try jwt.io to verify what I'm saying.

[psychok7]

@kitab15 i am not using angular but i found this that i can try https://github.com/auth0/jwt-decode

But how can it decode without knowing the secret key??

[psychok7]

Ok after reading a bit further i now understand why we don't need a secret key to decode like explained here auth0/jwt-decode#4 (comment)

I found this implementation as well https://github.com/sahat/satellizer/blob/31a1f03937656cc5227347355439f4b4386ad66d/src/shared.ts#L65

I also found that we can use RSA as mentioned here: #316 (comment) so that we can share the public key and encrypt with it, and then generate our own private keys in the client (maybe put it in local storage). If for some reason we loose the private key, we can always force a username/password login and generate a new one.

[orf]

Tokens are signed, not encrypted. Even the slightest of reading into jwt's should have shown you this. You don't need a secret key to read them but only to verify them, and if you use a private key to sign them then you can verify then with the public key.

…

On 4 May 2017 17:15, "Nuno Khan" ***@***.***> wrote: Ok after reading a bit further i now understand why we don't need a secret key to decode like explained here auth0/jwt-decode#4 (comment) <auth0/jwt-decode#4 (comment)> I also found that we can use RSA as mentioned here: #316 (comment) <#316 (comment)> so that we can share the public key and encrypt with it, and then generate our own private keys in the client (maybe put it in local storage). If for some reason we loose the private key, we can always force a username/password login and generate a new one. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#330 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-sh-jetJ8_wfJlwBGxHnqhxDH8WyI6ks5r2fm_gaJpZM4NQi3c> .

[psychok7]

@orf i Guess when we are learning new tech we might miss some important points (or maybe not even think about the actual meaning until we need to). Nevertheless thanks for you explanation

[orf]

Sorry, I didn't mean to come across as brisk! Check out https://jwt.io for a good resource and help.

…

On 4 May 2017 21:15, "Nuno Khan" ***@***.***> wrote: Closed #330 <#330>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#330 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-shyNe5uxPbH0OQHdYrEFWfLfoxJM2ks5r2jG2gaJpZM4NQi3c> .