Last updated on Sep 2, 2024
- All
- Digital Authentication
Powered by AI and the LinkedIn community
1
Use HTTPS
Be the first to add your personal experience
2
Choose the right storage location
Be the first to add your personal experience
3
Set expiration dates
Be the first to add your personal experience
4
Implement refresh tokens
5
Here’s what else to consider
Tokens are pieces of data that authenticate users and grant them access to protected resources on web applications. They are often used in conjunction with APIs, OAuth, and OpenID Connect protocols. But how do you store tokens securely in web browsers, where they can be vulnerable to theft, leakage, or misuse? In this article, we will explore some of the best practices for storing tokens in web browsers, such as using HTTPS, choosing the right storage location, setting expiration dates, and implementing refresh tokens.
Top experts in this article
Selected by the community from 2 contributions. Learn more
Earn a Community Top Voice badge
Add to collaborative articles to get recognized for your expertise on your profile. Learn more
- Rafael Pereira Software Developer
1
1 Use HTTPS
One of the most basic and essential practices for storing tokens in web browsers is to use HTTPS, or Hypertext Transfer Protocol Secure. HTTPS encrypts the communication between the browser and the server, preventing anyone from intercepting or tampering with the tokens. HTTPS also ensures that the browser is connecting to the legitimate and trusted server, not a malicious or spoofed one. To use HTTPS, you need to obtain a valid SSL certificate from a certificate authority and configure your server to serve HTTPS requests.
Help others by sharing more (125 characters min.)
2 Choose the right storage location
Another important decision for storing tokens in web browsers is where to store them. There are three main options: cookies, local storage, and session storage. Each option has its own advantages and disadvantages, depending on your security and usability requirements. Cookies are small files that are sent by the server and stored by the browser. They can be accessed by both the server and the browser, and they can have expiration dates and flags to limit their scope and visibility. However, cookies are also susceptible to cross-site request forgery (CSRF) attacks, where a malicious site can trick the browser into sending a request with the cookie to the target site. Local storage and session storage are part of the Web Storage API, which allows the browser to store key-value pairs of data. Local storage persists across sessions, while session storage is cleared when the browser is closed. They can only be accessed by the browser, not the server, and they have more storage capacity than cookies. However, they are also vulnerable to cross-site scripting (XSS) attacks, where a malicious script can read or write the data in the storage.
Help others by sharing more (125 characters min.)
3 Set expiration dates
A good practice for storing tokens in web browsers is to set expiration dates for them. Expiration dates limit the validity and lifespan of the tokens, reducing the risk of token reuse or compromise. Expiration dates can be set on both the server and the client side, depending on the type and format of the token. For example, JSON Web Tokens (JWTs) are self-contained tokens that encode the expiration date in their payload. The server can verify the expiration date when validating the token, and the browser can check the expiration date before sending the token. Alternatively, the server can maintain a list of valid tokens and revoke them when they expire or when the user logs out.
Help others by sharing more (125 characters min.)
4 Implement refresh tokens
A common challenge for storing tokens in web browsers is how to handle token expiration and renewal. One solution is to implement refresh tokens, which are long-lived tokens that can be used to obtain new access tokens, which are short-lived tokens that grant access to resources. Refresh tokens are usually stored securely on the server side, while access tokens are stored on the browser side. When an access token expires, the browser can request a new one from the server using the refresh token. This way, the user does not have to re-authenticate every time, and the access tokens are refreshed frequently.
Help others by sharing more (125 characters min.)
- Carl Gieringer Software Engineer at Google
- Report contribution
Thanks for letting us know! You'll no longer see this contribution
"Refresh tokens are usually stored securely on the server side" this is technically true, but misleading. Clients must also store refresh tokens or else they couldn't send them to the server to obtain access tokens.Browsers should store refresh tokens in Secure HttpOnly cookies to prevent XSS. Server endpoints recognizing the refresh token must not have any side effects (other than generating and returning a new access token) to prevent CSRF. Clients must not make the access token accessible to cross-origin JavaScript: i.e. never store it somewhere accessible from the global `window` object, such as in `window.localStorage`. Store it in-memory only, and call the server to get a new one on app startup.
LikeLike
Celebrate
Support
Love
Insightful
Funny
5 Here’s what else to consider
This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?
Help others by sharing more (125 characters min.)
- Rafael Pereira Software Developer
(edited)
- Report contribution
Thanks for letting us know! You'll no longer see this contribution
JWTs may not always be the optimal choice for your specific requirements. This could be due to the absence of built-in expiry revocation or the potential vulnerability of having a plaintext payload (If the information is too sensible), in which case storing it unencrypted at all may not be the best choice. In these instances Phantom Tokens could be a viable alternative, instead of implementing workarounds – your clients can store Opaque Tokens, and a dedicated Token Service can convert them into a previously generated JWT accessible exclusively to your back-end. This allows you to enjoy the benefits of a enhanced security, addressing the limitations posed by JWT's in certain scenarios (at the cost of statelessness.)
LikeLike
Celebrate
Support
Love
Insightful
Funny
1
Authentication
Authentication
+ Follow
Rate this article
We created this article with the help of AI. What do you think of it?
It’s great It’s not so great
Thanks for your feedback
Your feedback is private. Like or react to bring the conversation to your network.
Tell us more
Tell us why you didn’t like this article.
If you think something in this article goes against our Professional Community Policies, please let us know.
We appreciate you letting us know. Though we’re unable to respond directly, your feedback helps us improve this experience for everyone.
If you think this goes against our Professional Community Policies, please let us know.
More articles on Authentication
No more previous content
- How do you deal with MFA and 2FA failures and recovery options?
- How do you implement multi-factor authentication without annoying your users? 1 contribution
- What are the benefits and challenges of using SAML for single sign-on (SSO)? 2 contributions
- What are the common challenges and best practices of implementing MFA and 2FA?
- How do you test and validate Kerberos and SSO functionality before and after a system upgrade or migration?
- What are the benefits and challenges of implementing DMARC for email security?
- How do you measure and improve the effectiveness of your MFA and 2FA policies? 3 contributions
No more next content
More relevant reading
- HTML5 How do you handle CORS and CSP compatibility across different browsers and devices?
- Web Applications How can you ensure a seamless web application user experience across all platforms?
- Programming How can you ensure secure code when working with cookies?
- HTML How do you implement fallback solutions for local storage and cookies in older or unsupported browsers?