You are not logged in.
Pages: 1
Hello everyone, I would like to know if anyone has implemented any way to renew jwt token when it expires?
Offline
Probably I misunderstood the trouble. Anyway, maybe it will help you.
We have TJWTAbstract-based JWT generating (RS256) for one of TSQLHttpClient-based clients. Time-expiration is stored in a separate variable and before each request it makes a check and renews JWT if needed (TJWTAbstract.Compute) with saving new time-expiration, of course.
Offline
Yes, but wouldn't it be slightly slower?
And one more question concerning the client-side, if you don't mind.
I had to use TSQLHttpClient.OnEncryptBody event for forming custom headers (incl. bearer JWT) and URL parameters for Every request, but the meaning of OnEncryptBody is a bit another as far as I understand. Is there any better way to do that?
Offline
You store the JWT token on the client side, so you can store the expiration date/time too.
It won't be slow to check the date/time (using UnixTimeUTC).
For setting the JWT, rather use the TSQLRestClientURI.SessionHttpHeader property.
Offline
Is it safe to renew the token automatically?
In the APIs that I use and implement, the renewal of the Token is the client responsibility.
If a request is made with an expired token, the server only rejects the request. Then the client must renew the token again.
Offline
You store the JWT token on the client side, so you can store the expiration date/time too.
Well, it is pretty much the same as I wrote before.
For setting the JWT, rather use the TSQLRestClientURI.SessionHttpHeader property.
I missed that property. It is useful for customizing headers and perfectly fine for JWT-auth header, thanks!
But since we need to use custom URL parameters for that implementation, I think I'll continue using OnEncryptBody for now.
Is it safe to renew the token automatically?
In the APIs that I use and implement, the renewal of the Token is the client responsibility.
I'm confused a bit, what can be the need for receiver (server, for instance) to renew the token? Moreover, the validating endpoint might have only public key for validation, so it will not be able to generate new JWT in that case (even if it would be needed). I assumed that the initial question was concerning the JWT issuer, was I wrong?
Offline
Hi Vitaly, thanks for the reply, I understand your suggestion, but my client is not a TSQLHttpClient but an Asp.net client. How do you think this token renewal policy would work in this scenario?
Offline
@Vitaly
Oh, forget it.
Got it really wrong.
The question is about the client ...
Sorry about the mess.
Offline
Hi Vitaly, thanks for the reply, I understand your suggestion, but my client is not a TSQLHttpClient but an Asp.net client. How do you think this token renewal policy would work in this scenario?
Sorry, I'm not proficient in Asp.net, can't help much. I would check the client for JWT/OAuth support, some clients might have automatic abilities for token renewal.
So far, in basic, I see only two ways of handling JWT expiration:
1. JWT Issuer/User (your client here) checks the JWT expiration time before request and renews it if needed (generates a new one or requests a new one in case of standalone auth-service).
2. Like @macfly suggested, renewal can happen in case of a token-expiration response from the server. But you'll have to know the error-response structure then, parse/analyze it, and have an ability to retry the same request with another auth-JWT header after renewal.
I prefer the first way - it seems for me faster and clearer.
Probably, somebody else here can suggest another way or/and help you with asp.net client implementation.
Offline
Ensure you use UTC timestamps for the expiration time, and that you give some additional period of time before the actual expiration, i.e. renew 15 minutes before actual time, since clocks may not be perfectly in synch.
And even if you make a JWT renewal from the client side using the expiration time, you better always handle the authentication errors, and try to renew the JWT.
Offline
I use both methods suggested by @vitaly.
A check in expiratron time. And also on demand.
Having the ability to renew on demand is important in cases where the token may expire due to a change in the user's account.
*Speaking in a generic way and not just in APIs created via mORMot.
Example, i use APIs where a change in the user's account (password, e-mail, etc.) causes the token to expire.
So just observing time of expiration is not enough.
But you have to be careful not to create an infinite loop in this check.
Offline
Ok, in case of a complete authentication error check do I perform a new authentication? For that I would need to store username and password locally, wouldn't that be a breach of security?
Offline
I believe that in case of authentication error (not token expiration), you should inform the user about it. And allow him to log in again.
You should not store your username and password locally.
Offline
Okay, what about an expired token? What to do?
Offline
It depends on the requirements.
For instance, web sites ask the password again, but there is a built-in password manager in the browser which remembers the password.
In mORMot SynCrypto, you have CryptDataForCurrentUser() which can be used to save the password in memory during the program execution, in a safe manner.
So I would use CryptDataForCurrentUser() to store the password in memory and renew the token before its expiration.
Offline
Hi Ab, I don't know if I understood the use of CryptDataForCurrentUser for sure. I send the token to the Asp.Net client through a correct Login URI. My ASP.NET client uses this jwt token in the next requests until its token expires. Where would the use of CryptDataForCurrentUser come in?
Offline
CryptDataForCurrentUser() is for a Delphi client for sure.
But you may use a similar feature from .Net, calling e.g. CryptProtectData() Windows API, to safely store temporary the password on your client side.
Offline
Thanks Ab, it clarified a lot. Thanks to everyone who responded, I will proceed with some .net client-side resolutions now.
Offline
Pages: 1