We’ve got PSU running with OIDC authentication (MS Azure/Entra) and client secret credentials currently, but security requirements obligate us to rotate that every 90 days. If we swap to certificate credentials, we can move to a much longer rotation period and save ourselves some busy-work every quarter.
Sidenote: I just remembered a thread/discord from years ago, regarding the OIDC auth working without specifying a valid secret value. I thought that was a bug that would be fixed.
Seems like that’s not the case, as my secret expired a month ago but still works. I just tried deleting my Client secret, both in azure, but also in appsettings - still works.
Certificate based auth would be nice, but a workaround seems to just let it expire, or delete the secret entirely.
Even if this would work on Microsoft’s end, it’s in no way an acceptable solution for us. It’s a large entreprise environment and it’s not optional. The security requirements have teeth.
Sure, but what added security does a client secret add, if the functionality is the same with or without a valid Client secret?
it seems to work without a CS, with an expired CS, and random letters.
Having a Client Secret does nothing to prevent the use of the integration, as anyone else effectively just needs to know the TenantID and App ID. The only layer of “security” seems to be the allowlist of redirect URLS.
I don’t disagree with you, but it’s outside the scope of my concern. Ironman Software can’t really help me with a bug or security issue with Microsoft Entra itself, but could potentially support a different assertion format to use with its OIDC configuration.
This sounds like potentially what I need to get facebook OIDC working (I’ve only been configuring OIDC with docker env vars so far) which I’ve had trouble with (ended up falling back to google OIDC which is fine) so while it’s a slightly different topic from OP, thanks for this answer, I’ll look into that for my issue too!
