Opsera allows users to generate personal access tokens which can be used with the Opsera API via standard RESTful APIs. Below is the documentation around creating and managing tokens and calling the supported Opsera APIs.
Personal Access Tokens
Users can generate and manage multiple personal access tokens. These tokens have a limited expiration date, targeted scope and can be expired early via the Opsera Portal if need be.
Generating a Token:
Log into the Opsera portal and click on your user name in the top right corner of the header and choose Profile:
Then select Access Tokens from the menu tab:
From this page users can create new tokens giving them unique names and setting their expiration windows and they can view the list current tokens and when they will expire. If a token is lost or no longer needed, users can expire that token in the table view below.
Token Lifecycle:
Tokens are never saved within the Opsera platform. It is the user’s responsibility to save it securely when generated, otherwise the token is lost.
When a token is created, Opsera will save only meta data about that token in the system. This is what is shown in the list of tokens at the bottom of the Personal Access Tokens page (see image above).
Tokens are generated with predefined scope. This means that a token with a pipeline scope can ONLY be used to perform pipeline actions. It could not be used for any other part of Opsera Platform’s APIs.
Tokens only work for explicitly defined Opsera API’s. A token will not work against any other API in the system.
When a new token is generated and the user saves it locally, they can then use it in tools like Postman or directly in their own scripts when calling the Opsera APIs treating it as a standard JWT based bearer token.
Token Access Rules:
A token follows the same access roles as the Portal UI. So if a user is a site Administrator OR site Power User, then they will have access to run the API’s against any supported objects (pipelines) in their organization.
If the user is the owner of the object (pipeline owner) then they will be allowed full access to perform actions on that item (same as in the UI).
Otherwise the system will evaluate the Role Access configuration for the object (as defined in the UI). So the user must be granted either the administrator, manager or user role at the object level in order to use the API.
In short the token acts just like a end user in the Portal. They must have proper access in order to perform the action. And if they do not, then the API simply returns “forbidden” to the end user.
Authentication Log:
Every time a token is used, the activity is logged in your Authentication Log. This log can be used to troubleshoot calls to the API and also ensure you are the only one using a token. You can view this for an individual token or for all of your tokens as shown below OR via the Opsera Audit Logging Token API (which itself would require a valid token).
