OpenID AzureAD Errors

[tip-dteller]

Hi,
We've enabled Azure Login and configured everything per the documentation.
however now after nearly 2 weeks - we started seeing this in the logs:
did not find expected authorization request details in session, req.session["oidc:login.microsoftonline.com"] is undefined

when does this happens:

• User goes to the custom url for librechat
• User clicks Azure Login
• User is directed to Azure Login page - enters credentials and MFA (with azure authenticator)
• Librechat logs the error above and shows the user "Internal Server Error"
• Page refresh - everything works normally.

If a user performs a LogOut operation - this happens again.
I was able to trace those requests in AzureAD, under its application and the logs and it appears as Interrupted on Azure side, due to Default Security settings - in other words, MFA.

Is there a particular configuration that is able to circumvent this without disabling security features which are naturally important.

Thanks

[TroRon]

I have exactly the same problem, if you know the solution, I would be very interested.

[danny-avila]

I can't really comment on what may help without seeing some configuration, with sensitive values redacted of course

could this be part of the issue?

FusionAuth/fusionauth-issues#153

Also if you're willing to share credentials so I can test this out, feel free to email me (on my github profile)

[TroRon]

So the exact same problem is not true, but it ends in an “Internal Server” error.

when does this happens:

The user goes to the provided URL
The user logs in using Azure Login
The user is redirected to the Azure Login Page - Enters the data

LibreChat reports:
did not find expected authorization request details in session, req.session[“oidc:login.microsoftonline.com”] is undefined

LibreChat writes the above error to the log and displays: “Internal Server Error”

Then nothing works anymore.

The configuration was done 1:1 as described here:
https://docs.librechat.ai/install/configuration/OAuth2-and-OIDC/azure.html

The content of the config looks like this (anonymized)
DOMAIN_CLIENT=https://xxxxx.xx #//localhost:3080 if not using a custom domain
DOMAIN_SERVER=https://xxxxx.xx # use http://localhost:3080 if not using a custom domain

OPENID_CLIENT_ID=xxxxxxxx-aaaa-4212-716-5dsfxx1f5xxxxxx
OPENID_CLIENT_SECRET=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxOPENID_ISSUER=https://login.microsoftonline.com/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
OPENID_SESSION_SECRET=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
OPENID_SCOPE=“openid profile email”
OPENID_CALLBACK_URL=/oauth/openid/callback
OPENID_REQUIRED_ROLE_TOKEN_KIND=id
OPENID_REQUIRED_ROLE_PARAMETER_PATH=“roles”
OPENID_REQUIRED_ROLE=“definied Group”

Unfortunately, I can't give you access, but can you tell me what else you need?

Detailed Error Log:
LibreChat | Error: did not find expected authorization request details in session, req.session["oidc:login.microsoftonline.com"] is undefined
LibreChat | at /app/node_modules/openid-client/lib/passport_strategy.js:132:13
LibreChat | at OpenIDConnectStrategy.authenticate (/app/node_modules/openid-client/lib/passport_strategy.js:191:5)
LibreChat | at attempt (/app/node_modules/passport/lib/middleware/authenticate.js:369:16)
LibreChat | at authenticate (/app/node_modules/passport/lib/middleware/authenticate.js:370:7)
LibreChat | at Layer.handle [as handle_request] (/app/node_modules/express/lib/router/layer.js:95:5)
LibreChat | at next (/app/node_modules/express/lib/router/route.js:149:13)
LibreChat | at Route.dispatch (/app/node_modules/express/lib/router/route.js:119:3)
LibreChat | at Layer.handle [as handle_request] (/app/node_modules/express/lib/router/layer.js:95:5)
LibreChat | at /app/node_modules/express/lib/router/index.js:284:15
LibreChat | at Function.process_params (/app/node_modules/express/lib/router/index.js:346:12)

[TroRon]

Now running, the following had to be changed so that it runs properly with an Azure group:

OPENID_REQUIRIRED_ROLE_TOKEN_KIND=id
OPENID_REQUIRED_ROLE_PARAMETER_PATH=“groups”
OPENID_REQUIRED_ROLE=“not the name, but the ID”

If necessary, the instructions would have to be adapted :)

[ncecere]

I have tried your changes @TroRon and I'm still getting the 500 error... can't tell if I did something wrong or not

# OpenID
OPENID_CLIENT_ID=<CLIENT_ID>
OPENID_CLIENT_SECRET=<CLIENT_SECRET>
OPENID_ISSUER=https://login.microsoftonline.com/<TENANT_ID>/v2.0/
OPENID_SESSION_SECRET=<SECRET>
OPENID_SCOPE=openid profile email
OPENID_CALLBACK_URL=/oauth/openid/callback
OPENID_REQUIRED_ROLE=<GROUP_OBJECT_ID>
OPENID_REQUIRED_ROLE_TOKEN_KIND=id
OPENID_REQUIRED_ROLE_PARAMETER_PATH=groups

Is there anything jumping out to you?

[ncecere]

I followed the steps at https://docs.librechat.ai/install/configuration/OAuth2-and-OIDC/azure.html step-by-step, got the Internal Server Error and found this discussion. After making the changes above still getting the same issue.

[TroRon]

Looks good to me, the same as mine.

Try regenerating the key on the Azure page under Certificates & Secrets.

I also had this error once, and then, deep in the logs at LibreChat, I saw that something seemed to be wrong with the secret.

After I regenerated it and entered the new one, it worked.

At best, Libre Chat stumbles with a character ....

Take a close look at the log file, you will see which error is thrown, based on the error you can see what you can do ;)

Just a guess ...

[tip-dteller]

Actually, ive gotten it on 3 different instances, 3 different azure sso definitions. Each has the same behavior. Quite frankly, im stumped

…

On Sat, May 4, 2024, 23:27 Ronny Troxler ***@***.***> wrote: Looks good to me, the same as mine. Try regenerating the key on the Azure page under Certificates & Secrets. I also had this error once, and then, deep in the logs at LibreChat, I saw that something seemed to be wrong with the secret. After I regenerated it and entered the new one, it worked. At best, Libre Chat stumbles with a character .... Just a guess ... — Reply to this email directly, view it on GitHub <#2212 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A6X5VJEVJE2PFSKNK4VURY3ZAVADZAVCNFSM6AAAAABFITI7WWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TGMJWGA4TG> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[TroRon]

Hmmm ...

I've just tested it again and it works perfectly ...

I have otherwise followed the instructions 1:1 ....

Except for the change mentioned

[ncecere]

The issue for me ended being on the loadbalancer side. I wasn't using shared storage for the web servers or stick sessions on my load balancer. Once I dropped down to a single web server it worked perfectly. I then enabled shared storage for the web server component and increase count and it all worked.

[ppatayane]

We started getting it as well intermittently 2 weeks back when we changed our setup to container based..
Below action fixed the issue for us, just enabling the session affinity 🙂
https://learn.microsoft.com/en-us/azure/container-apps/sticky-sessions?pivots=azure-portal#configure-session-affinity

[maxesse]

I had this issue too since yesterday, it started happening as I had more traffic and the replicas started autoscaling. I already had session affinity set on the containers, as well as cookie affinity on the azure WAF in front of the application (even if it's useless given the container app cluster is exposed as a single backend server).
I fixed it by deploying an azure redis cache and enabling USE_REDIS and REDIS_URI in .env, now the sessions are shared across the replicas and it seems to work fine.

[Schluggi]

Thank you for the hint. This fixed it for us as well :)

[mrn-linak]

Could you demonstrate the format of the REDIS_URI? We are trying to achieve something similar, but I'm getting some errors and I just want to ensure my connection string is in the right format.

[maxesse]

Something like rediss://:apikey=@instancename.redis.cache.windows.net:6380

[mrn-linak]

Thanks! Much appreciated.

[d-teller]

@danny-avila
I know redis is experimental.
When turned on it does help with multiple replicas and the login flow as you'd expect when deployed on k8s.
But the message about "flushing the cache" is ambiguous.
We experienced a very odd behavior because of that.

I spun an instance with Redis turned on and some UI features.
When I came about it to change those UI settings, they didnt take affect.
I didn't assume that the configuration for librechat would be persistent in redis.

As the use of redis is experimental, this behavior should be noted