{"id":209,"date":"2025-07-06T14:11:36","date_gmt":"2025-07-06T13:11:36","guid":{"rendered":"https:\/\/discovery.cevolution.co.uk\/ciam\/?p=209"},"modified":"2025-10-28T12:13:28","modified_gmt":"2025-10-28T12:13:28","slug":"spotlight-on-the-ciam-token-storage-conundrum","status":"publish","type":"post","link":"https:\/\/discovery.cevolution.co.uk\/ciam\/2025\/07\/06\/spotlight-on-the-ciam-token-storage-conundrum\/","title":{"rendered":"Spotlight on the CIAM Token Storage Conundrum"},"content":{"rendered":"Reading Time: <\/span> 16<\/span> minutes<\/span><\/span>\n

From a CIAM perspective, a B2C<\/span>\/B2B<\/span> SaaS application will typically deal with a number of different Tokens, each used for a different purpose and each expressed in a particular format. An ID Token<\/strong><\/span>, for instance \u2014 used by an application to identify an authenticated user and build the user session \u2014 is expressed as a JWT<\/span>. <\/p>\n\n\n\n

An Access Token<\/strong><\/span>, on the other hand \u2014 used when calling an API on behalf of a user \u2014 is more often than not expressed as a JWT, but could equally be an opaque artefact requiring the use of Token Introspection<\/em>. Whilst a Refresh Token<\/span><\/strong> \u2014 used primarily to recreate an expired Access Token without user interaction \u2014 is typically opaque.<\/p>\n\n\n\n

Each token has a purpose that is well-defined. But how should one go about storing each of them in a way that ensures safety and security? Should they all be treated in the same manner? Or should some be considered more precious than others? As vehicles for identity and data access, tokens are attractive targets for malicious actors<\/span>; how and where they are stored, then, becomes a crucial aspect of a secure CIAM implementation. <\/p>\n\n\n\n

Earlier this year, I came across the following post on X\/Twitter (whichever your preference \ud83d\ude09) that sparked some debate. I often find it amusing how the various 3rd-party SaaS CIAM vendors go back and forth with each other as each one vies for their position as the superior solution. However, it does highlight an interesting point: what is the best approach to adopt when it comes to token storage, and which strategy offers the most protection long-term?<\/p>\n\n\n\n

\n
\n

Yesterday, a customer insisted that Auth0 recommends localstorage for long-lived session tokens in React

I could have sworn they strongly advise against it \ud83e\udd14

Wayback Machine shows they changed their guidance, and removed the link to OWASP that says not use localstorage \ud83d\udc40 pic.twitter.com\/1FPZ4JDp0L<\/a><\/p>— Colin | clerk.com (@tweetsbycolin) December 14, 2024<\/a><\/blockquote>