I've been wondering about the practice of authorization providers using session storage to keep tokens. From my perspective as a web developer, this approach seems to expose the app to risks like hijacking or script injection, which could compromise user security. While it's convenient for refreshing tokens without much effort on the client side, it clearly has its vulnerabilities. I'm curious why this method is so common among third-party providers, as it doesn't seem like many alternatives are widely discussed, such as using a server or proxy to manage internal validations.
4 Answers
I hope you aren't lumping all tokens together. If you're referring to client-side tokens, these are meant for backend interactions and typically have a short lifespan for basic permissions. But server tokens should never be stored on the client side. After authorization is granted, session ID tokens are usually passed to control access and rate limits for the web client. Generally, these are low-risk if exposed because they expire quickly, often within an hour, and permissions are limited to safe actions.
I prefer storing session tokens or authentication strings in HTTP-only cookies. Knowing that these are out of reach from JavaScript makes me feel a lot safer.
I'm not quite following you. Server-side session data can be secure as long as it's managed properly, which is what it's built for.
You're right about that! It's really best to stick with conventional web practices, like using sessions combined with cookies, rather than going for custom solutions that involve JWT and storage. Always remember, verification should happen on the server side when dealing with session data. Trusting client-side setups can be a big mistake! I'm curious, though, how often is session storage actually used for storing auth tokens in real-world apps?
Related Questions
How to Build a Custom GPT Journalist That Posts Directly to WordPress
Cloudflare Origin SSL Certificate Setup Guide
How To Effectively Monetize A Site With Ads