Keep users logged in
You asked
“Users complain they have to log in again every day. Can you keep them signed in for a month without a session store?”
The model answered
1// login2app.post('/login', async (req, res) => {3 const user = await verifyPassword(req.body.email, req.body.password)4 const token = jwt.sign({ sub: user.id, role: user.role }, SECRET, { expiresIn: '30d' })5 res.json({ token })6})7 8// client9localStorage.setItem('token', data.token)10fetch('/api/me', { headers: { Authorization: 'Bearer ' + localStorage.getItem('token') } })11 12// middleware13function requireAuth(req, res, next) {14 const token = req.headers.authorization?.split(' ')[1]15 try {16 req.user = jwt.verify(token, SECRET)17 next()18 } catch {19 res.status(401).end()20 }21}Classify each statement
0/9 classified. Some statements are true — the point is telling which.
Whether a 30-day bearer token is acceptable depends on what the application protects and who is expected to attack it.
The design has one long-lived token instead of a short-lived access token and a rotating refresh token.
Any JavaScript running on the page, including a compromised dependency or an injected script, can read the token and send it elsewhere.
Removing the session store is exactly what removes the ability to end a session early.
A self-contained token lets any instance authenticate the request without a shared session store.
The design needs to know whether "log out" must invalidate the token on the server or only forget it on the client.
The middleware rejects tokens whose signature does not match the server secret.
Changing a password, disabling an account or detecting a stolen token has no effect on tokens already issued.
The verification call accepts whatever algorithm the token header declares.