This is a series of posts divided into the following parts:
- Handling JWT securely on your client - Part-1
- Handling JWT securely on your client - Part-2 [THIS POST]
- Handling JWT securely on your client - Part-3 - not yet published
- Handling JWT securely on your client - Part-4 - not yet published
Summary
- Part-1 covers the main problem statement around jwt security in web-apps; presents a few options and evaluates them
- Part-2 dives deep into overcoming limitations around the chosen option in Part-1 e.g. SSO, Silent Authentication/Refresh, etc.
- Part-3 talks about non web-apps i.e. backend rest clients that don't run on web browsers e.g. postman
- Part-4 talks about other values added flows such as jwt expiry, force logout etc.
Handling JWT securely on your client - Part-2
Quick recap
In the part 1 of this blog series, we established that in-memory storage is most secure way of storing jwt.
We also established that this approach brings about two limitations:
- Limitation 1: SSO: Hampers the ability to implement SSO
- Limitation 2: Session: Hampers user experience by forcing him/her to login on every tab/window A subset of Limitation 2 is that the user is forced to login when they close their browser and reopen it
More on the limitations
Limitation 1: SSO
Limitation 1 can only be solved with some sort of state management on the Authorization server. The server needs to retain information on all users who have logged in.
But this goes directly against the principles of using jwt, which are meant to be stateless.
Limitation 2: Session
Limitation 2 can only be solved with some sort of state management on the client browser side. The client needs to persist some information that is available across browser tabs and also across browser restarts.
But if you are thinking of persisting jwt (through localStorage or cookies), go to PART-1 of this series! I repeat - we will keep the jwt in-memory only
Top comments (0)