3 Scenarios Where You Can Store JWT Token in Your DB | by Aindrila Choudhuri | Jul, 2022

Know when and why

Picture by Kelly Sikkema on Unsplash

Token-based authentication (most frequently JWT primarily based) is known as stateless authentication — as a result of the authentication server doesn’t want to take care of any state, the token itself accommodates all the required info to confirm a token bearer’s authentication.

The server can seamlessly test whether or not the JWT accommodates the required details about the consumer’s id and authorization to carry out an motion with out querying the database. Now the query arises, if such is the situation then do we have to save the JWT token within the database? If sure, then when and why?

I’ll attempt to cowl three eventualities the place the need to avoid wasting the tokens in DB arises.

Earlier than we dive deep into the subject let me provide you with a tiny introduction on entry tokens and refresh tokens. When a consumer logs in, the authorization server points an entry token (usually JWT), then the shopper can use this token to make safe API calls.

When the shopper must entry any protected useful resource from the server on behalf of a consumer, it attaches the token within the request header which helps the server to find out the authenticity of the shopper/consumer. Entry tokens have a really quick lifespan (usually no more than 30mins).

As soon as the entry token expires the shopper software can immediate the consumer to re-login (which is definitely not an excellent consumer expertise) or the shopper can use a refresh token which is issued by the authorization/authentication server to generate a brand new entry token.

Refresh tokens usually have a a lot larger life span than the entry tokens. They might or is probably not JWT. Refresh tokens generally is a easy encoded string or a UUID. Refresh tokens are additionally bearer tokens, therefore ​malicious customers can theoretically steal the refresh token and use it indefinitely to entry protected sources from the server. Then how will we safe our software from malicious customers accessing protected sources?

Essentially the most simple reply to this query could be saving refresh tokens within the database and revoking entry of all customers by deleting all of the refresh tokens when any such malicious conduct is reported. However what if it’s not reported, will we let the malicious consumer entry protected sources indefinitely? Will we carry on saving refresh tokens in our database?

The reply to this query is refresh token rotation, refresh token reuse detection and deleting all previous refresh tokens when a brand new one is generated. Let me attempt to clarify my reply — when a brand new entry token is generated (on the time of check in/signup or utilizing a refresh token) — a brand new refresh token also needs to be generated (that is referred to as refresh token rotation), and all of the earlier refresh tokens should be deleted.

On this approach — even when a malicious consumer steals the refresh token, when the professional consumer tries to log in to the applying, a brand new entry token and a brand new refresh token might be generated, and all different refresh tokens might be deleted, if the malicious consumer tries to make use of the previous refresh token the refresh token reuse detection would already detect the reuse or the refresh token wouldn’t exist in DB. This manner we will stop a malicious assault.

A verification electronic mail is shipped out to a consumer electronic mail tackle (which he/she makes use of to register), after they register into an software. This electronic mail accommodates a hyperlink with a token generated by the server for that consumer ID, when the consumer clicks on the hyperlink an API request is made to the server with this token (electronic mail verification token). These tokens all the time have a brief expiration time.

The server must confirm this token for that consumer electronic mail. However what if the consumer clicks on the resend verification electronic mail once more even earlier than the present hyperlink/token’s expiration? To deal with such eventualities tokens should be saved in DB — both all of the tokens or solely the most recent one (when a brand new token is generated previous tokens are deleted).

Since all or a couple of token is energetic at this second, JWT verification would go for any of the tokens, however we should always examine solely with the most recent one. As soon as verification is completed, all the e-mail verification tokens for that consumer should be deleted.

When a consumer clicks on forgot-password and enters his/her electronic mail tackle, an electronic mail is shipped out to the consumer containing a hyperlink (which accommodates a reset password token). These reset password tokens additionally usually have a brief lifespan.

As soon as a consumer clicks on the hyperlink, he/she must enter the brand new password, and as soon as clicked on reset password an API request is made to the server containing the brand new password and token despatched within the electronic mail hyperlink. The explanation to avoid wasting/not save this token is fairly just like email-verification-token. If the consumer clicks on the neglect password greater than as soon as and receives a number of emails (all earlier than the token’s expiry).

On this case, we have to retailer all of the tokens in DB or the most recent one (when a brand new token is generated the previous tokens needs to be deleted). After a consumer clicks on the hyperlink, the token within the API request payload is matched with the most recent token in DB for that consumer, and all of the reset-password tokens for that consumer should be deleted.

JWT permits the server to carry out stateless authentication by checking the token content material. If in any case a couple of JWT will be generated for a consumer for a single function like an electronic mail verification token, or reset password token in these circumstances we should save the tokens/newest token in DB to match with the newest one. Equally, in case of refresh token (JWT or not) — we have to reserve it in DB to revoke and stop malicious consumer entry.

Code, learn, and alter the world!

More Posts