Authentication fails due to In collectInfoFromReq: missing state in the request for some users

[SamDuvall]

Over the past couple weeks, I've had a few users report they can no longer sign in via Azure SSO that had been able to previously. I can see through my logs that In collectInfoFromReq: missing state in the request and In collectInfoFromReq: invalid state received in the request are frequent errors.

I cannot figure out why only some users are having this issue and I haven't been able to reproduce it myself. I've tried useCookieInsteadOfSession to no avail. Does anyone have any suggestions for what could be going on?

[Jalle19]

We started the same issue all of a sudden today

[andreidiaconescu]

• I am working on a new integration with Azure Openid Login using node and passport and this node module
• This issue keeps reproducing every time the redirect is done, so i am kind of stuck.

{"name":"AzureAD: OIDC Passport Strategy","hostname":"32cc8a3ae54e","pid":603,"level":30,"msg":"authentication failed due to: In collectInfoFromReq: invalid state received in the request","time":"2019-10-22T15:19:57.095Z","v":0}

• Where can i see the value of the state sent to Azure SSO ?
• the value of the state received from the Azure SSO in the redirect Post is under the key "state" i assume, but i guess the value is encrypted; for example: i use as state 'my_state' but i see in browser console for the redirect url http://localhost:4040/auth/azure/callback, the value cgIqlI5hKxG2NT2RL55XZ3bCvSJXdCPm;
• how could i see the decrypted state value ?
  Thank you.

[andreidiaconescu]

• i found a reason why the previous error was producing in my case: azure was not sending the state in the cookies, and this only happened when i was running the application locally on a url like http://0.0.0.0:4040;
• after a lot of investigations, when i switched to http://localhost:4040 the state was sent ok in cookies.

[mowday]

I am also experiencing this issue. For me, it seems to be connected to decrypting the cookie. Namely these rows:

passport-azure-ad/lib/cookieContentHandler.js

Lines 169 to 172 in ee2ec66

	var decipher = crypto.createDecipheriv('aes-256-gcm', key, iv);
	decipher.setAuthTag(authTag);
	var decrypted = decipher.update(content, 'hex', 'utf8');
	decrypted += decipher.final('utf8');

The underlying error is: TypeError [ERR_INVALID_ARG_VALUE]: The argument 'encoding' is invalid for data of length 11. Received 'hex'

If I change row 171 and 172 to:

var decrypted = decipher.update(content);
decrypted += decipher.final();

Then it starts working for me.
Proof of concept gist: https://gist.github.com/mowday/d9dde7886dc30055064e7d4b737b8351

Is this the same issue?

Edit: Just FYI, I'm running on Node v13.3.0

[bburhans]

In my case, invalid state and a resulting error was only happening for iPhone and MacOS users due to Apple's unwillingness to backport SameSite='none' cookie support. Check if you have iOS 12 or MacOS 10.14 browsers affected and sameSite or sameSiteCookie are in use.

Edit with references: https://www.chromium.org/updates/same-site/incompatible-clients and https://bugs.webkit.org/show_bug.cgi?id=198181

[mowday]

I have tested it on LTS (v12.14.1) and confirm that the problem doesn't occur there, but can reproduce it consistently in v13.3.0

[ilkkaparssinen]

Had the same problem when we moved from Node v12 to 13.5.0. mowday's fix to cookieContentHandler worked for us, too. node.js behaviour seems to have slightly changed in version 13 - related documentation issue: nodejs/node#29786.

I tested mowday's fix also with node v12.13.1 - it didn't break anything there. It seems that it would be safe to incorporate the fix to the main library.

[jdthorpe]

I get this error when running on docker using FROM node:latest (13.8.0-stretch) but not when using FROM node:lts (12.16.0-stretch) or when running in node (v10.15.3) on my windows machine.

Here's a minimal reproducible example, should the Azure-AD team dive into this problem: changing this line to FROM node:latest will cause the above error.

[bburhans]

@jdthorpe I had the same issue after upgrading from another 13.x version to 13.8.0 to fix the recent vulnerabilities. I haven't yet found the root cause, but I did work around it by setting useCookieInsteadOfSession to false. I did confirm that browser issues were not the cause; the cookies and state do match on both ends of the OIDC flow. I'll keep investigating, but if session state is compatible with your use case, try that instead of cookies in your passport-azure-ad config.

[cerinoligutom]

I use Docker with node:12-alpine image. I got this error after deploying to our production environment. I tried @bburhans suggestion to set useCookieInsteadOfSession to false but that didn't work either. What first struck me was why doesn't this happen during local development so I tried to diff what are the differences between the two environments and at this point, the environment variables are the only things to look at. Turns out if NODE_ENV is set to production, I can replicate this error.

Any ideas as to why is that and how to fix this?

[rhummelmose]

Why is this not being fixed?

[justiman1]

Any updates on this issue?

[CodeWilliamson]

I have not had the issue since setting the SameSite attribute on the cookie to 'none' and secure to true. This means that you must run your app behind HTTPS. I have deployed this to our testing server behind HTTPS and it works fine. I still have the issue on my local dev machine because I'm running on HTTP.

[pkanher617]

Hi all, is this still an issue in the latest version of passport-azure-ad? We are currently in the design phase of a new version of this library, which can be tracked here. The timeline for the new library will be uploaded to our MSAL JS repo.

We will ensure to cover issues with state in the design phase here.

[sameerag]

Closing this. Please track our new repo as requested