...
Log into the Opsera portal and click on your user name in the top right corner of the header and choose Profile.
...
2. Select Access Tokens from the sub-navigation menu:
...
3. Select the Scope, provide a unique Name and set Expires After date. Then click the Create button to generate the token.
...
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.
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.
Token Access Rules:
A token follows the same Access Roles as the Portal UI. 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 Userrole at the object level in order to use the API.
In short, the token acts just like an end user in the Portal. They must have proper access in order to perform the action. If they do not, the API simply returns “forbidden” to the end user.
...