OpenID Connect documentation is wrong for Azure AD

[dlloyd]

Product: PowerShell Universal
Version: 1.4.6

The documentation regarding OpenID Connect using Azure AD as an authentication source is incorrect. I advise that no one attempt to try it until Ironman Software corrects it.

Incorrect documentation regarding OpenId Connect:
xhttps://docs.powershelluniversal.com/config/security/openid-connect

I followed the directions three times from scratch and the result is Azure AD returns an error about the callback path not matching.

"OIDC": {
  "Enabled": "true",
  "CallbackPath": "/auth/signin-oidc",
  "ClientID": "82f42207-0659-4b62-8b5e-85fbfd436d24",
  "ClientSecret": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "Resource": "",
  "Authority": "https://login.microsoftonline.com/96b5b2b3-dd98-499e-b83c-1402305fb7d9",
  "ResponseType": "id_token token code",
  "SaveTokens": "true",
  "UseTokenLifetime": true
  "ClientCertificate": {
  "Enabled": "false"
}

Azure AD Callback Paths:
http://localhost:5000/auth/signin-oidc
http://localhost/auth/signin-oidc

Neither of these paths is apparently correct.

[OtherPeoplesCode]

For what it’s worth, I have OIDC working as-is (using the same documentation you linked). For reference, this is my appsettings.json file:

      "OIDC": {
        "Enabled": "true",
        "CallbackPath": "/auth/signin-oidc",
        "ClientID": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
        "ClientSecret": "xxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "Resource": "",
        "Authority": "https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
        "ResponseType": "code",
        "SaveTokens": "false",
        "CorrelationCookieSameSite": "",
        "UseTokenLifetime": true,
        "Scope": "openid profile groups",
        "GetUserInfo": true
      }

Then in the Azure app registration I have the default ‘http://localhost:5000/auth/signin-oidc’ and added the custom URL I have setup for the site (e.g. “https://psu.company.com/auth/signin-oidc”):

[PorreKaj]

@dlloyd

ClientSecret

One misleading thing here, is that you need to type the ID of the secret. Not the value.

[dlloyd]

Greetings,

I have just tried the client secret key instead of the actual secret and that also leads to the same error that the URL doesn’t match what Azure AD has for allowed URLs. I have followed the instructions exactly so I am hoping that Ironman Software can improve the error handling of that portion of the code. I’ll skip OIDC until the bug is fixed or the documentation is corrected.

(upload://4Jp1jlKHrbaERJGcyVgigbKVBL4.png)

(upload://pPLrSVI9jDZjQqWLSOqItW9HJt3.png)

Thank you for your help PorreKaj and OtherPeoplesCodev

[insomniacc]

Hey dlloyd,
I wouldn’t flat out advise people not to attempt OIDC based on your experience with the PSU docs, a lot of people use this currently and have had no problem getting setup using the official docs as they are - even if they could do with some tweaking to make things clearer, based on my experience I didn’t see that they were incorrect.
Also your statement about Ironman software improving error handling - it doesn’t really apply here, your config is wrong and the error is coming from Azure, not from PSU, this is not a bug.

That aside, here is my config if it helps you get going:

"OIDC": {
      "Enabled": "true",
      "CallbackPath": "/auth/signin-oidc",
      "ClientID": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
      "ClientSecret": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
      "Resource": "https://graph.microsoft.com",
      "Authority": "https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
      "ResponseType": "id_token token",
      "SaveTokens": "true",
      "CorrelationCookieSameSite": "",
      "UseTokenLifetime": true,
      "Scope": "openid profile",
      "GetUserInfo": true
    }

The Client ID being the application ID of your app registration:

Client secret is the value (not the ID as previously mentioned in this thread) of a registered client secret under the same app reg:

My app reg auth page looks like this:

[insomniacc]

Also, based on the error youre getting from azure, the call back that PSU is making, is not matching what you have registered in your app reg.
I’d do a couple of things here, confirm that its coming from http or https, add both if necessary.
Also, make sure you’re logged out of azure when you attempt to try PSU login using OIDC, when you get to the login page, check the call back url as it’s being made in the browser address bar, it’ll look something like this:

https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/oauth2/authorize?client_id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&redirect_uri=<CHECK-HERE>&resource=https%3A%2F%2Fgraph.microsoft.com&response_type=id_token%20token&scope=openid%20profile%20groups&response_mode=form_post&nonce=........

Look for the redirect_uri= in the address.
Best to do this in a incognito tab incase there’s any cached logins already and it doesnt try to make the attempt.

[PorreKaj]

I notice that your URL’s all are HTTP, are you 100% sure that your are not accessing through HTTPS? seems a bit strange to implement sign in on HTTP

[adam]

Also note that you’ll need to use HTTPS for the redirect back to PSU to work in Chromium. Using HTTP will result in a 500 error, as mentioned in the docs.

[dlloyd]

Greetings Adam,

I can confirm that the error appears on non-Chromium based browsers as well.

PorreKaj: We have the free version so I am forced to use HTTP for now until I can prove to management that it is a viable system. So far OIDC and published folders are not working so I am creating workarounds for them until Iron Man Software addresses the issues.

Thank you all!

[dlloyd]

Hi insomniacc,

I do believe PowerShell Universal OIDC doesn’t work with the free version. Not sure if it is intentional or even known by Iron Man Software but I have a feeling now that I paid for it and am using HTTPs, it will work. Just need to get into my account first…