Passing Auth from App to API

Hello @SunnyJ

Thank you for the detailed explanation.

I agree that passing the username as part of the POST data would not be ideal for audit purposes, since that value could be supplied by the caller rather than derived from the authenticated session.

According to the current documentation, when the API security model is set to Strict, calls made from a user context such as an App are authorized using that user's privileges. Permissive can also communicate the user context when it is available. However, the documentation does not explicitly confirm that this should result in $Identity being populated inside the destination endpoint in the exact App to API scenario you described.

Since you are running PSU 2026.1.2, I would like to validate this behavior specifically against that version before recommending a configuration change. There was also a change in 2026.1.4 that added support for -Integrated with Strict API security mode, so I do not want to apply behavior from a newer version directly to your environment.

Could you confirm:
• Which authentication method the App is using, such as Forms, Windows Authentication, or OpenID Connect?
• Whether ApiSecurityModel is currently configured in both appsettings.json and .universal\settings.ps1, and what value is set in each location?

You only need to provide the relevant configuration lines.

Because this is a public forum, please sanitize all evidence before posting. Remove credentials, tokens, license keys, cookies, private keys, full connection strings, email addresses, usernames, customer data, tenant or account identifiers, internal domains, hostnames, IP addresses, and private URLs. Please do not upload unredacted HAR files, memory dumps, database backups, or complete configuration files to this public thread.

References:
https://docs.devolutions.net/powershell-universal/config/module
https://devolutions.net/powershell-universal/release-notes/

Best regards,
Ruben Tapia

Hello Ruben,

I've tried it with both Strict and Permissive.

My current related settings are:

#Relevant settings in appsettings.json
"Api": {
    "SecurityModel": "Strict",


"Authentication": {
    "Windows": {
      "Enabled": "true"
    }

#Settings in settings.ps1
$Parameters = @{
	LogLevel          = "Error"
	DefaultPage       = "Home"
	EnhancedAppTokenSecurity = $True
	ApiSecurityModel = "Medium"
	NotificationLevel = "Warning"
	DarkTheme         = $True
}
Set-PSUSetting @Parameters
	

We have both Windows authentication and anonymous auth configured in IIS, but this is specifically using Windows Auth.

I did some further testing of what variables are available in the API when accessed by the App using:

Get-ChildItem Variable: | Out-File D:\PSU\ScriptLogs\Temp.txt

There were no variables in that Temp.txt file that listed a username when using Invoke-PSUEndpoint.

Let me know if you need any more information.

Hello @SunnyJ

Thank you for providing those additional details.

With the Windows Authentication configuration, the Strict and Permissive test results, and the relevant settings from both appsettings.json and settings.ps1, we now have enough information to build a closer reproduction of your scenario in our lab.

We will use those details to replicate the App to API flow and specifically verify how the authenticated user context behaves when Invoke-PSUEndpoint is used.

Thank you again for the detailed testing and information.

Best regards,
Ruben Tapia

Hello @SunnyJ

We completed our initial lab testing and were able to reproduce the behavior consistently.

In our tests, calls made through Invoke-PSUEndpoint reached the target API successfully, but the authenticated user identity was not exposed to the endpoint through $Identity or related variables. We observed the same behavior with both Strict and Permissive security models, and the result was repeatable across our test runs.

At this point, the evidence suggests that authorization and user identity propagation are behaving as separate concerns in this App-to-API flow.

As an additional validation step, tomorrow we will repeat the core tests using PSU 2026.3.0 to confirm whether the latest version changes this behavior before we finalize our findings.

I will update the thread once that comparison is completed.

Best regards,
Ruben Tapia

Hello @SunnyJ

We completed the additional validation using PSU 2026.3.0 and were able to reproduce the same behavior.

Across PSU 2026.1.2, 2026.2.3, and 2026.3.0, the destination API does not receive $Identity or $Username when invoked through Invoke-PSUEndpoint. We also confirmed the behavior is consistent under both Strict and Permissive security models.

Our testing indicates that authorization and caller identity propagation are handled separately in this App-to-API flow. The request can reach the API successfully, while the authenticated user's identity is not propagated into the target endpoint variables.

The behavior was repeatable in our testing, including the latest 2026.3.0 version, so this does not appear to be a regression limited to your 2026.1.2 environment.

Based on these results, the next step is to submit the findings and supporting evidence for Development confirmation regarding the expected identity propagation behavior of Invoke-PSUEndpoint.

I will update the thread once we have additional information.

Best regards,
Ruben Tapia

@rubentapia @SunnyJ Thank you for the report and the work to track down this issue. I've opened an issue in our backlog to take a look in development to see if we can get this fixed.