Azure Authentication Setup Issues

I swear I’m following documentation step by step to get things configured for Azure authentication at

I’ve tried both the appsettings.json method as well as authentication.ps1.

Any examples of working configs I can look at or other documentation I can follow?

appsettings.json method

"OIDC": {
      "Enabled": "true",
      "CallbackPath": "/auth/signin-oidc",
      "ClientID": "fffffff-0000-1111-2222-333333333333",
      "ClientSecret": "dodsonhere",
      "Resource": "",
      "Authority": "",
      "ResponseType": "id_token token",
      "SaveTokens": "true",
      "CorrelationCookieSameSite": "",
      "UseTokenLifetime": true,
      "Scope": "openid profile groups",
      "GetUserInfo": false


Authentication Method

Set-PSUAuthenticationMethod -Type "OpenIDConnect" -CallbackPath "/auth/signin-oidc" -ClientId "clientid-here" -Authority "" -ResponseType "code" -Scopes "openid profile groups"

It looks like the webpage at might be having issues, or it may have moved permanently to a new web address.

This was a HTTP 500 earlier… don’t know what’s up with that.

Product: PowerShell Universal
Version: 2.8.3

How many groups does your user have? I’ve seen this before when there were too many groups for the server to handle. Are you hosting in IIS?

It’ll be a lot of groups, but it’s not bringing me to authenticate against azure yet so can’t imagine it’s too that point yet.

Yes sir, hosting in IIS.

Well I was wrong, it’s getting me to Azure. Upon completion of auth, this is where i land in an incognito session. Any logs I should be checking?

This page isn’t working right now can’t currently handle this request.


ClientSecret parameter not being set in authentication.ps1. Set it manually in the PS1 and it works.

IMHO, one thing I would suggest is go to the Azure App Registration and target specific user(s)/group(s) you will allow access to PSU, then in the App Registration’s token configuration select to only include groups assigned to the application. This cuts down on token bloat, and is probably best from an OpSec perspective to not unnecessarily expose users’ group memberships.

That’s true, except that it kills your ability to use nested groups. In my case I have to use ‘Only groups assigned to application’ because we’re a fairly large organization with loads of groups. I’ll be working on transitioning to a 1:1 no-nesting format unless I figure out a different way to do it.

Yeah, you’re absolutely right. We do our best to avoid nesting groups (“one group, one purpose” mantra). Definitely recognize my suggestion doesn’t work in your setup.

I wish I had found this thread before as it would have saved me several weeks of aggravation. As of today, this is what I found about setting up OIDC in PowerShell Universal as a web app in azure:

The recommended method, I.E. going to authentication and setting up OIDC from “Add authentication method” DOES NOT SAVE THE CLIENT SECRET. I finally solved the 500 error by going to Configurations/Authentication.ps1 and inserting the client secret there. Thanks to rp53 for that.

Now for the real kicker: Once you’re ready with OIDC and are prepared to remove Form Authenticationto secure your site, DO NOT remove by disabling it from the Authentication section. If you do that, it will overwrite the OIDC section and remove the Client Secret again.

Finally, this is the line as it worked for me:

Set-PSUAuthenticationMethod -Type “OpenIDConnect” -CallbackPath “/auth/signin-oidc” -ClientSecret “Client_Secret_Here” -ClientId “Client_ID_Here” -Authority “” -ResponseType “code” -Scopes “openid profile groups”

Trying to add more variables to that line, like ‘-Resource “”’ results in an error.

I hope this helps other people trying to get this to work.

Hey @adescic,

Apologies for all the aggravation. We’ve identified the issue that was causing the secret to not save. It was actually clearing the secret in memory even though it persisted in the authentication.ps1 file. The really bummer with this bug is that all it took to remove the secret was to visit the authentication page. This is resolved in our next 2.x and 3.x versions.

1 Like

Hi @adam ,

That’s great to hear, thanks for the update!