Opsera allows users to generate personal access tokens which can be used in order to trigger features of the Opsera platform via standard RESTful APIs. This documentation covers token creation and management as well as a list of the currently supported API’s.
...
3. Select the Scope, provide a unique Name and set Expires After date. Then click the Create button to generate the token. Please Note, the scope of the token MUST MATCH the action you wish to perform with the token.
...
4. Your unique token can now be copied. Please note: This token will not be able to be accessed again.
...
Tokens are NEVER saved within the Opsera platform. It is the user’s responsibility to save it securely. If a token is lost, a new one must be generated.
The user who generates the token is the owner of that token. All actions take with that token apply RBAC permissions based on that user. So if you share your token with someone else, and they use it, you will be the user who shows up in the activity logs and your access in Opsera will be what they have access to (based on predefined scope).
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.
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 the site’s available API’s.
Tokens only work for explicitly defined Customer 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.
When a token is used in the API, it passes through these layers of validation:
1. It is validated to verify that it’s an authentic Opsera token and that it’s currently an active (not expired) token.
2. It’s checked to verify the user owning the token is still valid in Opsera.
3. is checked against the Personal Access Token’s repository settings to ensure the token is not de-activated by the end user/owner.
4. Its scope is compared to the operation being requested.
5. If the scope matches, the Opsera API will validate if the user has access to the given object they are trying to perform the action on. If it’s a pipeline, it will determine if the owner of the token is the owner of the pipeline. If not, it will check if the token owner is a site administrator or site power user (both of which have blanket access to use customer APIs) and if none of that is the case, the individual Role data associated with an object is then evaluated. If NONE of those checks pass, then the user will be rejected. To summarize: a token must not only be active and valid but also must have explicit access to the object they are trying to perform the action on. Otherwise the access will return a “forbidden” response.
...