## Problem Statement GitLab has [developed several tokens](https://docs.gitlab.com/ee/security/token_overview.html) over the years with an iterative approach, but without the investment into a modern authorization architecture. At least 10 tokens have been developed to solve various use cases with very similar patterns. As a result, the current token designs have deficiencies, lag behind industry standards, and has increased maintenance for several teams. These deficiencies are outlined on this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/474881 "Tokens: Problem Discovery") which covers challenges with: * Permission model * Maintenance * Engineering constraints * Current user experience * Industry and Competitive ## Proposal **Key Features** * **Single token service:** Consolidate the majority of tokens into a single token service. Access would be based on the Principal (see below). * **Fine-grained permissions:**  Provide the ability to define permissions to resources from scratch for a token to enable Principle of Least Privilege. * **Access**: A principal is defined as user or machine. User access is based on membership of groups and projects. Machine access is based on allowlist. * **Temporary credentials:** Offer short-lived refresh access to reduce risk of persistence access. * **Organizational controls:** Define policies for tokens to follow specific rules across multiple groups or projects. * **Auditability:** Offer comprehensive logging of the token to improve detection and response workflows.  #### Design Token Policy 1. Fine-grained permissions: Start from zero and add permissions. The term "scopes" is not used here as this concept is reducing access. 2. Principal: * User: Access granted to group or project based on membership of user. * Machine: Access granted to groups or projects defined in the allowlist. 3. Group and project access allowlist: Specify what group and project the token can access. * \*\*Ideas: Specify all projects (wild card) in a group with a shortcut. Mirror project access to each other. 4. Rules: Limit source IP address, max expiration allowed, allowable permissions 5. Organizational control: Apply the token policy to groups and project to enforce a standard. #### Bookmarks * [Technical vision on tokens](https://internal.gitlab.com/handbook/engineering/development/sec/govern/authentication/technical-vision/#token-unification---draft) * [Token management standard](https://handbook.gitlab.com/handbook/security/token-management-standard/) * [GitLab Workload Identity Federation](https://gitlab.com/groups/gitlab-org/-/epics/13974 "GitLab Workload Identity Federation") * https://gitlab.com/groups/gitlab-org/-/epics/3559+ #### Outcome 1. Deliver a unified, flexible, and secure token experience to access GitLab resources. 2. Consolidate existing [tokens](https://docs.gitlab.com/ee/security/token_overview.html) and keys to reduce maintenance across teams. 3. Continue to develop fine-grained permissions that can be applied to a single token model instead of multiple token models. --- This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.