Token Change Proposal

[bp4151]

Unless I am missing something, at the present time, a service token represents access to a project and configuration, and a personal token represents global access limited to the scope of the associated user. The current documentation recommends the use of a Personal Token for functionality not covered by a Service Token, but because of the scoping of Personal Tokens, if a Personal Token attached to a user with an Admin role is required to access certain functionality, then this essentially goes against least privilege best practices and is for all intent and purpose, exposing additional functionality unnecessarily.

I am proposing a change for clarity and an additional token type.

1. Change the current Service Token to Project Configuration Token, since this is what this type of token really represents from a scope/authorization perspective
2. Keep the Personal Token, as that makes sense from the perspective of authorization based on user role.
3. Add a new token type that allows scoping to API objects/endpoints that is not tied to the user and name that token type Service Token, since that more accurately represents what it is e.g a token whose authorization is based on service scoping.

Why does this matter?
We currently have a token type that can work with projects and configurations
We currently have a token type that is scoped to user access
We currently do not have a token type that is scoped to areas of functionality.

We want to be able to read and create integrations via API, but this functionality isn’t scoped to a project and configuration, so we can’t use Service Tokens. We have to use a Personal Token with enough permissions (e.g. Admin) to perform this action. If we want to, for example, create an AWS lambda that can create integrations for us based on some event, we need a personal token, which is a violation of least privilege security best practices. We don’t want an Admin level token hanging out in AWS that has access to everything. We would love to have a Service Token (as opposed to a Project Configuration Token) that we can scope to the purpose of creating integrations and nothing else.

[thomasp]

Have you checked out Service Accounts? They’re variably-scoped and not associated with a specific user’s identity. It sounds like they’ll accomplish what you’re looking for.

The current documentation recommends the use of a Personal Token for functionality not covered by a Service Token

Could you point me to those docs? I’d love to get those updated to instead recommend Service Accounts (which are relatively new).

[bp4151]

1. I must have misinterpreted this
2. I missed Service Accounts since I was doing my PoC on my personal account, not work account and didn’t have access to that functionality.

I’ll run this through again using my work account and a Service Account token and see if I can make this work.