Node.js中加密与签名Cookie的疑问及Passport.js相关问题

Let's break down your questions one by one with clear, practical explanations:

1. Cookie type, sessionID relationship, and req.secret issue #

That cookie format (s:x05d6V5Dhf6efFGjIkO26Ka1.imN4lT7OhW83Nc9Z7vw5dFbCoQhanP3aa37iyNWQyvU) is definitely a signed cookie — the s: prefix is express-session's standard marker for signed cookies. The reason req.signedCookies returns an empty object is because your app isn't properly exposing the secret to the cookie-parsing middleware. Since req.secret is undefined, Express can't verify the signature, so it won't populate req.signedCookies.

And yes, your req.sessionID matches the part before the dot exactly as intended: express-session stores the session ID as plaintext (before the dot) plus an HMAC signature (after the dot) to prevent tampering. The session ID is indeed stored directly in the cookie.

2. Purpose of the secret in express.session #

The secret you set in app.use(express.session({ secret: 'blablablabla' })) is used to sign the session cookie, not encrypt it. Express uses this secret to generate the HMAC signature appended to the session ID. This ensures the cookie's content (the session ID) hasn't been altered by a user — it doesn't encrypt the session ID, which remains plaintext in the cookie.

3. cookie-signature module capabilities #

That statement is correct: the cookie-signature module only handles signing and verifying signatures, it can't decrypt anything. Signing is a one-way process (using HMAC) that confirms the cookie's integrity, not reverse-engineer encrypted content.

As for using an old session secret to verify: if the cookie was originally signed with that old secret, yes, you absolutely can use it to validate the signature. The signature is generated using the secret and the raw session ID, so matching the original secret will let you confirm the cookie hasn't been tampered with.

4. Cookie storage location #

The cookie itself is stored in the user's browser — it's sent back and forth with every request to your domain. The full session data associated with that session ID might be stored in MongoDB if you're using a session store like connect-mongo, but the cookie only holds the session ID. Your server uses this ID to look up the actual session data in your chosen store.

内容的提问来源于stack exchange，提问作者user1584421