We recently setup open id authentication with our azure tenant. I setup open id via the GUI and we used a self signed cert to allow open id to work in our office via the local IP of the PSU server, this worked perfectly and I would get automatically logged into PSU since I was already logged into office/azure in my browser.
Our problem started occurring when we moved from the local IP to a public url proxied through a cloudflare tunnel. We switched the open id url to the public url and at first everything looked like it was working fine but after logging in once to PSU via azure open id and clicking to stay logged in on the office 365/azure login prompt we get stuck redirecting from office/azure to PSU. It will just keep loading.
Something strange I noticed is I am now unable to edit the open id settings via the front end. When attempting to do so I get an “Error” toast in my browser with no other information.
Any ideas/pointers are appreciated, still very new to PSU so let me know if there are some logs I should check/add to this post.
A little more info. Tried changing the max header request size since we use a lot of groups. I think this was at least partially causing issues. The login issue still persists however. Whats strange is logging in via an incognito browser works great, but then trying to log back in when already logged into office it hangs on a redirect
I made some changes to the odic config and we are now running into a 500 error. Since the cloudflare tunnel is the most recent addition to our setup prior to me messing with the odic config we are currently assuming it is causing the issues but we can’t confirm. Here is the most recent log in our server’s log file:
2022-12-23 14:24:46.347 -05:00 [ERR] Message contains error: 'invalid_resource', error_description: 'AADSTS500013: Resource identifier is not provided.
Trace ID: 9bb0031b-59e4-41a6-9c79-972658090101
Correlation ID: dc041862-172a-4bfc-a03e-158988b8dd6d
Timestamp: 2022-12-23 19:24:46Z', error_uri: 'error_uri is null'.
The resource field for our odic config is blank and the response type is set to “id_token token” as I would like to use the user’s token for things like azure automations. Save token is enabled, use token liftime is enabled too. Get claims from user endpoint is disabled and the scopes are set to the defaults provided.
Correlation cookie samesite is set to none as Im not clear on what the setting means.
Got to messing with it more today. Seems like the 500 error occurs only when requesting a token response, requesting a code response leads us back to the issue originally stated.
Strangely the issue doesn’t seem to occur in browser on the PSU host server even though I am visiting the public url proxied through cloudflare
Figured out the issue when using token as the response type, I think a resource was required for that to work as well as some permissions for that resource. I added https://manage.office.com/ as a resource in PSU and granted some delegated api permissions in azure.
Now we can see we are getting a token response from azure via my browser’s dev tools but we are back to the infinite redirect issue which I think points to cloudflare. Really new to cloudflare tunnels and using cloudflare services in general so any suggestions are welcome including using a different service known to work well with PSU.
Co-workers seem to get a 520 http error when logging in, PSU adds this to the logs when that occurs:
2022-12-28 09:49:29.217 -05:00 [ERR] Connection id “", Request id "”: An unhandled exception was thrown by the application.
System.Exception: An error was encountered while handling the remote login.
—> System.Exception: OpenIdConnectAuthenticationHandler: message.State is null or empty.
— End of inner exception stack trace —
at Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler1.HandleRequestAsync() at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication1 application)
Unsure if the request and connection id are sensitive, I assume not but just to be safe I removed them from the log message provided.
