Question about: JWT Refresh Stategy

[cosmic wolf]

Hi guys!

Am building a Spring Boot backend with a React Native (Expo) Frontend

My question revolvs around a good strategy for the JWT refresh token that am gonna use.

1: Stateless JWT token refresh without a database
- Harder to revoke if stolen

2: Opaque non-rotating, (UUID in the database)
- Basically a random string with UUID that is stored in the database that the backend will check towards
- can revoke from database if stolen

3 Opaque rottation token
- Generates a new UUID in the database on each refresh.
* This one seems harder to do but more secure on the long term.
- The new UUID invalidates the old one on the refresh

What would you do and do you got any tips or tricks? 🙂

[tender patrol]

<@&1004656351647117403> please have a look, thanks.

[low acorn]

Spring has a authorization server that handles it all for you

It's a fully fledged oauth implementation

[tender patrol]

@cosmic wolf

Your question has been closed due to inactivity.

If it was not resolved yet, feel free to just post a message below
to reopen it, or create a new thread.

Note that usually the reason for nobody calling back is that your
question may have been not well asked and hence no one felt confident
enough answering.

When you reopen the thread, try to use your time to improve the quality
of the question by elaborating, providing details, context, all relevant code
snippets, any errors you are getting, concrete examples and perhaps also some
screenshots. Share your attempt, explain the expected results and compare
them to the current results.

Also try to make the information easily accessible by sharing code
or assignment descriptions directly on Discord, not behind a link or
PDF-file; provide some guidance for long code snippets and ensure
the code is well formatted and has syntax highlighting. Kindly read through
https://stackoverflow.com/help/how-to-ask for more.

With enough info, someone knows the answer for sure 👍

[rough yoke]

Not sure if this kind of help is allowed, if not, mod please remove...

I have a video that kind of explains some things with JWT + Refresh Tokens

You want short lived JWT, and longer living Refresh Tokens.

https://youtu.be/D1eq9JkrqpY

[low acorn]

Any resources that help answer a question is fine @rough yoke , even if it's your own

[rough yoke]

didn't wanna like "self-promote" and get shunned lol

but I also happened to have a video on this topic 😛

If you watch this video, and still have questions @cosmic wolf feel free to Ping me for some more details

[glossy finch]

you can use redis for refresh token. You will get good performance

[low acorn]

deffo not

one of the good things about these tokens is that you don't need to store them in a database managed in the backend.

if you introduce redis or any backend cache then you're effectively wasting resources

[glossy finch]

Then how about storing only the revoked tokens in redis? Is this bad? If yes then how will you handle revoked tokens? They have long expiry time right?

[rough yoke]

personally...

I do store the refresh token into a DB

@low acorn if I'm wrong, what is a better way?

This wa how I learned it

[low acorn]

yeah the refresh token is created using your private key, so as long as the signature is valid, you can trust that you were the one that issued the key

thus, you're fine to accept it and perform whatever logic is needed

the only time a database should contain your access/refresh tokens is when a token was revoked. you store it in your database in some "revoked_tokens" table and set the ttl of the record to the expiry of the token

[low acorn]

it's fine as long as your cache isn't evicted, i prefer using a normal db e.g. postgres, mysql though. you don't need to use caching

by default, the data in redis would clear on restart / crashes etc.

which is why it's not the best place to be doing it

as a users revoked refresh token (which might expire in a few days/weeks/months) might all of a sudden be usable again (unrevoked)

[glossy finch]

Is redis crash is frequent in real world?

[rough yoke]

I feel like the lack of persistance, makes it less reliable

where it only caches

[low acorn]

no but you're relying on a non-persistant db which is the problem

a simple restart and game over so if you're doing an upgrade, maintaince, whatever, powercut then gg

[glossy finch]

Then how about multiple redis cache. If one down another can work?

[rough yoke]

I feel like that's crossing a line, and making the system as a whole, slower

plus, more fail points

[low acorn]

then you have to query all your redis caches

and they have to be hosted on different servers

having multiple redis nodes only help with availability but what we're talking about is durability

you need to think more with your security hat on and mitigate against all the points of failure

on the other conversation here about storing jwt's in the DB - if your database is leaked (and say you're a bank), an attacker could query your JWT table and essentially send money from EVERYONES bank account to their own

you'd only realise your database was breached after all the money is gone

[cosmic wolf]

Interesting reading, thanks for the input guys

[mystic plank]

are you talking about the spring security library or something else?

[low acorn]

yeah

[mystic plank]

your message makes it sound like there's an actual external server that spring apps can delegate security to

[low acorn]

spring-authorization-server is the dependency

but you can delegate it to an oauth provider like keycloak

[gentle wing]

2, 3. Don't provide the same benefits that are provided through JWT.

I see a lot of people using JWT (refresh & access tokens) with an in-memory database; That way it can be revoked and you still get the benefits of less database calls.

https://auth0.com/blog/denylist-json-web-token-api-keys/

[rough yoke]

but in mem brings the same issues as redis, a reboot and it's gone

[gentle wing]

Then you just change the secret that's used to encode them...

And require everyone to get new tokens.

[low acorn]

your statement and the link conflict

oauth0 is not recommending storing your JWTs into any database unless it's for revoking (which is what we're been saying)

you don't need an in-memory database to store JWTs. It's the client's job to store their own JWT

[gentle wing]

you need to store something if you want to revoke a jwt token

[low acorn]

exactly what i just said..

[gentle wing]

that is what the article says, and what i have been saying

[gentle wing]

great, so your ping was pointless!

[low acorn]

but you don't want to use in-memory for this

[gentle wing]

glad we agree

[gentle wing]

i didn't say you absolutely needed to use in-memory, but ive seen a lot of people use in-memory for that exact purpose

[low acorn]

yeah they're dumb - ignore them or educate them

the same concept applies to jumping off a cliff, just because others do it, doesn't mean you should

there are too many cons to an in-memory database for when the server restarts. it'll greatly impact your user experience and you're also removing the flexiblity JWTs originally gave

[gentle wing]

how often do you restart your servers?

[low acorn]

only when there's maintaince, ideally

or a new deployment

[gentle wing]

right

so where is the issue

[low acorn]

user revokes their jwt - your server had an update and restarted - jwt no longer revoked?

[gentle wing]

if you restart your server, you can rotate your key that is used for encryption

force everyone to get a new key, and therefore users that are banned or whatever, will be unable to perform that action

[low acorn]

great now you're adding operational overhead which is rotating keys, everyone is forced logged out of your app

[gentle wing]

but again, this is a niche case because nobody is restarting their server

[gentle wing]

exactly

[low acorn]

yes but people are doing deployments all the time

[gentle wing]

then they are doing something wrong

[low acorn]

sure, go tell that to every single fortune 500, oh and email everyone at FANG

make sure to tell them why your in-memory db solution is better and that the issues they had was a skill issue

[gentle wing]

fanng is not operating from a single server, and is using jwt..

i never said that they HAVE to use a in-memory db

i said, litterally what you said

so, where is the issue

[low acorn]

it seemed you were asking what the issue with in-memory was, not this conversation

if you agree then all good, myb

[gentle wing]

i was not asking that