That’s all addressed in the follow-up article/flowchart…
Sven Slootweg
1

I think security vulnerability is the wrong word, it’s more of a business decision if you will deny users access to your service if you invalidation store is down.

Assuming that someone gets hold of the end user token fx by breaking SSL or the security on the device it’s stored and at the same also finds a way to bring down the invalidation store remotely is not very likely.

Or put in another way you pretty much most of the same issues with any other solution, but have the added issues of some being able to DOS you infrastructure fairly easy by taking out your session store(under the assumption that it’s as easy to take out as the invalidation store). Also having a central session store adds a lot of complexity and makes it much harder to build loosely coupled infrastructure.

As a side not, the refresh token could have a hard fail check, meaning the short timeouts for the access tokens would not be a problem.

Security is always a trade-off, so a good solution is has to protect against realistic issues so it does not impose to many other problems.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.