Content
View differences
Updated by Dominic Bräunlein about 1 year ago
**As** an administrator
**I want to** set up system-level tokens
**so that** can use them as authentication in my SCIM client to provide it access to the OpenProject SCIM server API.
**Acceptance criteria**
* System-level tokens function similarly to personal access tokens but are associated with a designated system user.
* Tokens are limited by specific scopes.
* Administrators can create, name, and manage these tokens via a dedicated menu entry located at /admin/settings/authentication.
* Token have a name and are limited to specific scopes.
* The available scopes are api\_v3, bcf\_v2\_1 and scim\_v2. At least one Initially, the only selectable scope needs to be selected.
* Tokens can be set as valid for 1 day, 7 days, 1 month, 3 months or 1 year.
* After creating tokens is the token will be only visible once. SCIM API scope, which is selected by default.
* Multiple active system-level tokens can exist simultaneously.
* Administrators can delete individual tokens through an available menu action.
* Expired token should have a label called expired
* Expired tokens should be invalid when using them against the API
<br>
**Technical notes**
* I'd suggest to prefix them, so that we can recognize how to validate them, e.g. `opst-ABCDEF...` (**O**pen**P**roject**S**ystem**T**oken)
**Permissions and visibility considerations**
* Only accessible to administrators.
* Only available when the Enterprise plan Corporate is active.
<br> **Out of scope**
* Token expiration handling.
* Support for multiple scopes.
**I want to** set up system-level tokens
**so that** can use them as authentication in my SCIM client to provide it access to the OpenProject SCIM server API.
**Acceptance criteria**
* System-level tokens function similarly to personal access tokens but are associated with a designated system user.
*
*
* Token have a name and are limited to specific scopes.
* The available scopes are api\_v3, bcf\_v2\_1 and scim\_v2. At least one
* Tokens can be set as valid for 1 day, 7 days, 1 month, 3 months or 1 year.
* After creating
* Multiple active system-level tokens can exist simultaneously.
* Administrators can delete individual tokens through an available menu action.
* Expired token should have a label called expired
* Expired tokens should be invalid when using them against the API
<br>
**Technical notes**
* I'd suggest to prefix them, so that we can recognize how to validate them, e.g. `opst-ABCDEF...` (**O**pen**P**roject**S**ystem**T**oken)
**Permissions and visibility considerations**
* Only accessible to administrators.
* Only available when the Enterprise plan Corporate is active.
<br>
* Token expiration handling.
* Support for multiple scopes.