You can use PowerShell Universal app tokens with both and the . The management API uses the standard Administrator, Operator and Reader roles. The custom API app tokens can utilize custom roles as well as the built-in ones.
You can grant App Tokens to using the Admin Console or you can use the Management API directly.
Admin Console
To grant a token in the Admin Console, navigate to Security \ Tokens. Click the Create App Token button to grant an App Token.
When you click Create App Token, a dialog allows you to specify the Identity, Role and expiration time of the token.
Management API
You can also grant app tokens to users from the management API. To grant an App Token programmatically using the API, you can do the following:
Administrators can grant app tokens to any user by specifying the user's identity ID. To grant an app token to an identity via the REST API, the user needs a defined role. The Operator role defines the user, and their App Token will be granted access based on that role.
You can migrate app tokens between systems using the management API. This is helpful when developing for high availability scenarios.
The following is an example of the POST required to create an existing app token in any PSU instance. Note that the signing key must be the same between the instances. You need a valid app token in the target system to create the migrated tokens.
When enhanced app token security is enabled, token values are only accessible upon creation. They are hashed and the database stores the hash value rather than the token. You use the token the same way as any other token.
Enabling app token security will invalidate all existing tokens.
System Tokens
System tokens are a way to provide tokens to non-user systems. They are not tied directly to a user's identity. You can provide a name for the token as well as expiration and roles.
Signing Keys
Local Signing Key
By default, PowerShell Universal creates a signing key based on the Jwt \ SigningKey string in appsettings.json. This value is used to encode and decode the token. If the signing keys do not match, the token will be considered invalid. Changing the signing key will invalidate all existing signing keys.
Remote Signing Key
You may want to use an OAuth 2.0 discovery document to provide signing key validation. By using a remote system such as this, you can ensure that when signing keys are changed, the PowerShell Universal configuration will not need to be changed. To use a remote signing key, set the Jwt \ DiscoveryDocument value in appsettings.json to the URL of the OAuth 2.0 meta data document. When PowerShell Universal loads, it will read the signing keys from the document and provide them to the JWT validation system.
