The moment you open your browser, you’re likely to already have at least a few open. Sessions - one of the most fundamental building blocks of auth, is considered simple, yet that’s only surface level. Today, we’re taking that complexity apart, with the goal of understanding what makes it tick better.
\nYou’ve probably heard that the web is stateless. That’s an obvious problem when you’re trying to build software that needs to remember who’s logged-in. Put in layman’s terms, session-based authentication is a way of saying “I know who you are” between requests. To sprinkle a bit of tech speak on top of that definition, sessions introduce statefulness by keeping session data on the server. Every piece of session data is isolated to the user it belongs to.
\nLooking under the proverbial hood, key aspects of session-based authentication include:
\nBut, we need to go deeper.
\nThe process involves the following steps:
\nOkay, so the general idea isn’t that complex. But let’s take a short detour and see what makes session-based auth a good choice, especially in a world where token-based auth is also a thing.
\nSession data is stored on the server, making it less susceptible to tampering compared to client-side storage methods like local storage. The only data the client holds related to the session lives inside the HTTP-only cookie the server sets as reference (and that one can’t be tampered with).
\nAdditionally, the method you use to store the session data is largely up to you, the software author. Depending on what you’re trying to build, you might go for a database, and in-memory store or even the filesystem.
\nWe have plenty of choice when it comes to integrating a session mechanism in our apps - frameworks and libraries, such as express-session for Node.js, for one. Just searching for session on NPM, yields 1000+ packages:
This example isn’t going to do much by itself. Also, hardcoding usernames and passwords isn’t exactly the best practice ever, but it illustrates how sessions work. Now, we also have this via the SuperTokens SDK too - and you can set it up in less than 5 minutes :) Of course, anyone claiming they have a silver bullet for something is probably selling silver bullets. Around here, we’re more of the “right tool for the right job” mentality. So, sessions are not a silver bullet, and let’s have a look at some of their tradeoffs. Here’s the thing - storing stuff in memory (as in the example above), runs the risk of overwhelming said memory. Having a lot of users is a good problem to have, but make sure to use something like Redis (or similar) to make sure that their sessions actually remain accessible. The bottom line is, there’s a place and time to use session-based auth. Going the session way is probably a good idea if your app: Cool. Now let’s have a look at the alternatives. If what your building: it’s probably time to look elsewhere: We believe in giving you the tools to build the auth solution you need. We support both session-based auth and token-based auth. You can mix and match according to the requirements of your app. Check it out here. Session-based authentication remains an important tool in web application security. It wins on simplicity simplicity and control, where token-based approached win on distribution and scalability. Luckily, it doesn’t have to be either/or. Try SuperTokens today! And remember: security is a journey, not a destination. Keep learning, keep updating your knowledge, and never trust user inputs. 😉const express = require('express');\nconst sessions = require('express-session');\n\nconst app = express();\n\napp.use(\n sessions({\n secret: 'super-secret-key', // but, really, REALLY, keep this in one in ENV\n saveUninitialized: false, // don't create session until something stored\n resave: false, // don't save session if unmodified\n })\n);\n\napp.use(express.json());\napp.use(express.urlencoded({ extended: true }));\n\napp.listen(3000, () => console.log('Server is running on port 3000'));
\nCreating Routes and Handlers
\n\n
\nmodule.exports = function homeHandler(req, res) {\n if (!req.session.userId) {\n return res.redirect('/login'); // Redirect to login if not authenticated\n }\n\n res.setHeader('Content-Type', 'text/html');\n res.write(`\n <h1>Welcome back, ${req.session.userId}!</h1>\n <a href=\"/logout\">Logout</a>\n `);\n res.end();\n};\n\n
\n// handlers/login.js\nmodule.exports = function loginHandler(req, res) {\n if (req.session.userId) {\n return res.redirect('/'); // If already logged in, redirect to home\n }\n\n res.setHeader('Content-Type', 'text/html');\n res.write(`\n <h1>Login</h1>\n <form method=\"post\" action=\"/login\">\n <input type=\"text\" name=\"username\" placeholder=\"Username\" required /> <br>\n <input type=\"password\" name=\"password\" placeholder=\"Password\" required /> <br>\n <button type=\"submit\">Login</button>\n </form>\n `);\n res.end();\n};\n\n
\n// handlers/process-login.js\nmodule.exports = function processLoginHandler(req, res) {\n const { username, password } = req.body;\n\n // Simple authentication logic\n if (username === 'example-user' && password === 'password123') {\n req.session.userId = username; // Store userId in session, or any other info, for that matter\n return res.redirect('/'); // Redirect to home on successful login\n }\n\n res.status(401).send('Invalid username or password');\n};\n\n
\n// handlers/logout.js\nmodule.exports = function logoutHandler(req, res) {\n req.session.destroy((err) => {\n if (err) {\n return res.status(500).send('Failed to logout');\n }\n res.redirect('/login'); // Redirect to login after logout\n });\n};\n\n
\n...\napp.get('/', homeHandler);\napp.get('/login', loginHandler);\napp.post('/login', processLoginHandler);\napp.get('/logout', logoutHandler);\n...
\n\n### Running the Application\n\nAdd a `start` script to `package.json` and launch your server:\n\n```bash\nnpm start
\nRisks, Challenges, and Considerations
\nPotential Security Vulnerabilities
\n\n
\nSameSite and HttpOnly attributes.https. Which you probably should be doing anyway.Scalability Concerns
\n
\nWhen to Choose Session-Based Authentication?
\n\n
\n
\nAlternatives to Session-Based Authentication
\n\n
\n\n
\n\n
\n\n
\n
\nWhere SuperTokens fits
\n
\nConclusion
\n