Hey all, making a dashboard that gets information from the management API.
For authentication, I would usually just create and save a new token in a secret variable, but it feels wrong if I want to publish it as a module. It’s quite a static solution for someting that happenes server-side and expects the user to take manual action in addition to installing the module.
I’m interested to hear if there is a best practice to handle dynamic token creation (one-time and general use).
My name is Ruben Tapia from Ironman Software, and I will be assisting you with this thread.
Based on the current PSU v5 documentation, if this logic is running from an authenticated app, the documented approach is to use -GrantAppToken so the app can call the Management API in the visiting user’s context, instead of manually creating and revoking tokens on each use. (docs.powershelluniversal.com)
Also, the app token documentation notes that roles are embedded directly in the token and are not recalculated during use, so if a manual token is still required, using a minimal or custom role set would be the safer pattern. (docs.powershelluniversal.com)
To narrow this down, could you please confirm:
Your exact PSU version
Whether the app is configured as authenticated
The exact behavior you see from Grant-PSUAppToken in your environment
Any relevant PSU logs from the timestamp of the failure
Separately, I do see that the v5 changelog lists a fix in 5.6.0 for Grant-PSUAppToken response shows 0 for ID, although I am not yet certain that this is the same bug you are hitting. (docs.powershelluniversal.com)
I understand now that the Grant-PSUAppToken behavior you originally reported is already being addressed under GitHub issue #5603, and I can see that it has been closed against milestone 2026.1.6. Given that, the current 401 Unauthorized looks like a separate issue from the token-creation bug.
You are also correct that -GrantAppToken is the intended approach for authenticated apps calling the Management API. From there, the main thing I would verify is how the token is being passed during the REST call. In your screenshot, the Authorization = "Bearer ..." line appears commented out, so I would first confirm the final code is actively sending that header.
If the header is already being sent and you still receive 401, then I would next check whether PSU is behind IIS or another reverse proxy. In IIS specifically, if Anonymous Authentication is not enabled, app tokens may not pass through correctly. As an additional test, you could also try sending the token by using X-PSU-Authorization instead of the standard Authorization header, in case the proxy layer is interfering with that header.
If you would like, please share the exact app definition and the PSU log entries from the time of the request, and I will review them further.
From what I have gathered, GrantAppToken is used to grant permission for PSU-Cmdlets and is not a way to authorize REST calls. So it makes sense why I got the 401 error.
I’m looking to use the REST API (/api/v1/usersession) to get data inside a dashboard and I’m not sure what the best way to authorize to the REST API is, especially if the dashboard is intended to be installed over a module and I want to minimize manual setup.
In order to make the REST call, a token or password is needed. To get a token, I used the Grant-PSUAppToken to create a temporary token for the current user. I will take your advice and change that to minimal permissions.
If someone can think of a better approach or if im wrong about any of this, please let me know
Thank you for the clarification. That helps narrow the distinction quite a bit.
From the PSU v5 documentation, App Tokens are valid for both the PowerShell cmdlets and direct Management API REST calls, so using a token for /api/v1/usersession is still a supported pattern. The Management API documentation specifically states that REST calls require an App Token, and the Apps documentation states that -GrantAppToken is intended for authenticated apps that need to call the Management API in the context of the visiting user.
So, based on what you described, I think your current workaround is reasonable: generate a short-lived token for the current user and keep the assigned role scope as small as possible. The App Tokens documentation also recommends limiting role scope, both for security and to avoid oversized tokens.
I also agree with your broader point that this is not the most elegant experience for a module-backed dashboard scenario. A dedicated cmdlet for session retrieval would simplify that flow considerably. Your enhancement request is now formally represented in GitHub, so that product direction is at least documented for review.
Separately, Adam’s fix for the Grant-PSUAppToken issue should help on the token-creation side once that build is available, but for the REST authorization design itself, I do not currently see a more native v5 approach documented than using App Tokens for the Management API.
From my side, I will try to replicate this on my lab.
, and it still returns a 401.