OIDC and Windows Auth coexistence.
We have a deployment that we configured OIDC on and this is working as expected.
Now I have a use case for Windows Authentication for API endpoints. I am able to use Windows Auth properly when OIDC is disabled or Windows Auth is defined first. But Defining Windows Auth first breaks OIDC for the portal.
Is there a supported way for these two configurations to coexist?
We have PSU installed as a service and when OIDC is defined first I get a 401 unauthorized when trying to use the -UseDefaultCredentials parameter of Invoke-RestMethod against an API endpoint. I found reference to a header X-Windows-Auth but trying this did not change the result.
All Comments (3)
Hi rbaker1,
Thanks for the detailed write-up — that really helped pin this down.
What you're seeing is a known regression in PowerShell Universal, not a misconfiguration on your side. It's tracked as issue #4599: starting in v5.4.4, enabling both OpenID Connect and Windows Authentication at the same time causes Windows Auth to return 401 Unauthorized — which is exactly the failure you get from Invoke-RestMethod -UseDefaultCredentials. In v5.3.3, the two coexisted without issue. The "whichever provider is defined first breaks the other" behaviour you described is the same bug seen from both directions.
The good news is that it's been addressed and is assigned to the 5.5.0 milestone.
We recommend upgrading to 5.5.0 or later, enabling both providers, and re-testing your Windows Auth API endpoint.
That should restore the coexistence you had on 5.3.3.
On the X-Windows-Auth header: that isn't a supported switch for forcing Windows Authentication on a per-request basis, so it's expected that adding it made no difference. For Windows Auth, -UseDefaultCredentials (which performs Negotiate authentication, whether PSU runs under IIS or as a service) is the correct approach — the underlying bug is simply preventing it from being honored while OIDC is enabled.
If upgrading isn't immediately possible, the only reliable workaround on 5.4.4 is to run a single authentication method at a time. Some customers work around this architecturally by fronting the Windows-Auth API endpoints with a separate IIS site / reverse proxy that handles Negotiate, while leaving the portal on OIDC — but that's an infrastructure change rather than a setting.
Please don't hesitate to reach out if you'd like a hand validating the configuration after upgrading.
Best regards,
Patrick Ouimet
Unfortunately, this issue is happening on version 2026.2.0.0 for us. We were originally running 5.6.5 when we first tested this, and I tried updating to the latest version yesterday. The issue is present in both 5.6.5 and 2026.2.0.0.
Environment:
- PSU version: 5.6.5 and 2026.2.0.0
- Hosting: Windows Service / Kestrel, no IIS
- Service account: domain account
- SPNs: configured and validated
- OIDC provider: Entra ID
- API client: Invoke-RestMethod -UseDefaultCredentials
Results:
1. OIDC enabled only:
- Portal login succeeds.
2. Windows Auth enabled only:
- Invoke-RestMethod -UseDefaultCredentials succeeds against secured endpoint.
3. Windows Auth listed before OIDC:
- API endpoint succeeds with IWA.
- Portal OIDC breaks.
4. OIDC listed before Windows Auth:
- Portal OIDC succeeds.
- API endpoint returns 401 with -UseDefaultCredentials.
Conclusion:
This appears to still be an authentication scheme ordering/challenge issue in current builds, not the v5.4.4-only regression described in #4599.
Since we're seeing the same behavior in both 5.6.5 and 2026.2.0.0, I'm wondering if there may be another issue involved beyond the regression referenced in #4599.
To help us move forward, could you clarify whether the following scenario is currently expected to work in a single PSU instance running as a Windows Service (without IIS)?
- OIDC for portal authentication
- Windows Authentication (Negotiate) for API endpoints
- User-specific authorization based on the authenticated Windows identity
If this configuration is supported, would you be able to provide any guidance on the recommended configuration or provider ordering required to make the two authentication methods coexist?
If there are known limitations, special considerations, or outstanding issues related to this scenario in current releases, we'd appreciate any additional details you can share.
I've done further testing and found a configuration and workflow that allows the use of PSU with both auth mechanisms enabled.
With Windows Auth set as the first auth module the platform can be used with OIDC credentials but only if you visit the login page directly.
The API will accept Windows auth calls in this configuration the way I would like as well.
The only thing that doesn't work the way I anticipated with this configuration is that visiting the site without navigating to /login like going to /admin or /portal would trigger a Windows login instead of the OIDC logon we have been using.