In the original commit, anyone in possession of a token could attempt to
revoke it. Now, the caller (current_user) must be a Group Owner to
attempt to revoke a token.

Rate limiting is removed as we can now rely on the regular rate limits.
A malicious group owner can't add a random user and feasibly attempt to
brute-force their PersonalAccessToken. Nor can they find a leaked token
and brute-force a number of groups to try and revoke it against a
random one.

We can assume that a malicious actor with a token could use another API
endpoint if they wanted to (e.g. /user) to read information, update
records, or otherwise cause havoc.

So the next threat is a well-intentioned person trying to "help" when
they find a leaked token. A GitLab EM & maintainer both felt that the
risk of breaking an organization's systems by revoking a token was too
great and, therefore, revocation should only be possible if the caller
is a Group owner.

Added a "glffc-" prefix to the Operations::FeatureFlagsClient token

Changelog: changed
MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/144703

Prefixes CI Build tokens (a.k.a. CI_JOB_TOKEN) with `glcbt-` following
the guidance at
https://docs.gitlab.com/ee/development/secure_coding_guidelines.html#token-prefixes.

GitLab applies a prefix to some of its generated secrets. For example, a
Personal Access Token begins with `glpat-`. This MR adds a prefix to
Build Tokens. It also updates our frontend secret detection which
helps prevent users from leaking tokens via Issue / MR comments.

Build tokens belong to build jobs and are used to authenticate against
the APIs described at
https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html

Build tokens were already prefixed with a hexadecimal partition ID.
The new static prefix is placed before the existing prefix.

A feature flag is being used to reduce the risk of breaking CI pipelines
and/or third-party integrations, which might have made assumptions about
the format of GitLab's build tokens remaining static. The flag can be
enabled or disabled per namespace.

Resolves https://gitlab.com/gitlab-org/gitlab/-/issues/426137

Changelog: changed

Prefixes SCIM OAuth Access Tokens with `glsoat-` following the
guidance at
https://docs.gitlab.com/ee/development/secure_coding_guidelines.html#token-prefixes.

GitLab applies a prefix to some of its generated secrets. For example, a
Personal Access Token begins with `glpat-`. This MR adds a prefix to
SCIM Tokens. It also updates our frontend secret detection which
helps prevent users from leaking tokens via Issue / MR comments.

SCIM tokens can belong to a Group, or have no Group and be an instance
token. These tokens are used to authenticate against the APIs described
at https://docs.gitlab.com/ee/development/internal_api/#group-scim-api
and
https://docs.gitlab.com/ee/development/internal_api/#instance-scim-api
respectively.

A feature flag is being used to reduce the risk of breaking third-party
integrations, which might have made assumptions about the format of
GitLab's SCIM tokens remaining static.
See https://gitlab.com/gitlab-org/gitlab/-/issues/435096#note_1691498327
for discussion.

Resolves https://gitlab.com/gitlab-org/gitlab/-/issues/435096

Changelog: changed
EE: true

Prefixes Group & Project Deploy Tokens with `gldt-` following the
guidance at
https://docs.gitlab.com/ee/development/secure_coding_guidelines.html#token-prefixes.

GitLab applies a prefix to some of its generated secrets. For example, a
Personal Access Token begins with `glpat-`. This MR adds a prefix to
Deploy Tokens. It also updates our frontend secret detection which
helps prevent users from leaking tokens via Issue / MR comments.

It applies to both Group & Project tokens: `GroupDeployToken` `has_one`
`DeployToken`, and the latter is where the plaintext is generated. This
change means both types of deploy keys will be prefixed
`gldt-`.

Resolves https://gitlab.com/gitlab-org/gitlab/-/issues/376752

Changelog: changed

Also move FAQ from the blueprint to that page

Changelog: added