Auth flow doesn't complete when using AWS Lambda

[rbhalla]

Checklist

• The issue can be reproduced in the express-openid-connect sample app (or N/A).
• I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
• I have looked into the API documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

This is my configuration:

auth({
    session: {
      store: new RedisStore({ client: redisClient }),
    },
    // I manually specify which endpoints need auth when defining them
    authRequired: false,
    issuerBaseURL: process.env.ISSUER_BASE_URL,
    baseURL: process.env.BASE_URL,
    clientID: process.env.CLIENT_ID,
    clientSecret: process.env.CLIENT_SECRET,
    secret: process.env.SESSION_SECRET,
    idpLogout: true,
    errorOnRequiredAuth: true,
    routes: {
      postLogoutRedirect: '/logged-out',
    },
    authorizationParams: {
      response_type: 'code',
      audience: process.env.EXTERNAL_API_AUDIENCE,
      scope: process.env.EXTERNAL_API_SCOPE,
    },
  })

Locally this works fine. I've been using Serverless Framework to simulate lambdas on my machine, and the auth flow works correctly:

1. I hit /login
2. Middleware redirects to my issuer url
3. Auth0 redirects back to /callback
4. The middleware saves info to session, redirects back to /

In production, I also go through the auth flow all the way to step 4, and I even see a Success Login log entry in the Auth0 logs. However, I am not authenticated despite a session being persisted (in redis) with an access token.

Observations

• Locally the /callback endpoint sets an appSession cookie when it gets a code back. This doesn't seem to be happening in production. Another cookie is present on the final requests instead: auth_verification
• Despite not having attemptSilentLogin set to true, in production, I can see the skipSilentLogin cookie being set indicating it is being attempted. Locally, I have to login every time I logout, but in production I don't. This seems to indicate my config is not being respected in production, and yet, response_type is respected.
• Locally the sessions stored only have two keys present: id_token and state. In prod there are more keys: id_token, scope, access_token, refresh_token, expires_at and token_type.
• When I removed the response_type so the default is used (id_token), again this works fine locally, but in production I get a 400 (Bad Request) on my /callback route. I can see an id_token and state as part of the request, indicating the call from my tenant is correct. However, I get the following error:

BadRequestError: checks.state argument is missing
    at ResponseContext.callback (/var/task/node_modules/express-openid-connect/lib/context.js:354:15)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

My naive understanding of this code is that references to requests are being stored in memory. If that is correct, this middleware cannot be used in lambdas. However, another github comment seems to indicate it did work for them.

Reproduction

1. Create a simple app using the connect sample app
2. Export a handler using serverless-http as described here
3. Deploy to AWS lambda and try and hit /login

express-openid-connect version

2.16.0

Express version

4.17

Node.js version

16

[rbhalla]

A follow up, I ran this with DEBUG=* and it seems a little clearer that this is an issue with /callback not setting cookies correctly.

I would suspect my lambda was misconfigured and I wasn't setting cookies correctly, but /login is setting the transactionCookie correctly.

[rbhalla]

Seems like this was an issue with how AWS handles multiple set-cookie headers on a single response. TLDR: badly.

Not related to this library though, hopefully still useful for anyone who stumbles on the same issue.