Authentication
Last updated: Oct 27, 2026
When you authenticate a scan, the Fluid Attacks platform records who did each run. How you authenticate depends on who runs the scan: a person at a workstation signs in as themselves, and a pipeline or container authenticates as your group.
Most scanners still run without authenticating, but a future release will require it everywhere. A scanner that already requires it says so on its own page. We recommend adopting it now so your runs are attributed to your group.
Start here
| Who runs the scan | Authenticates as | How |
|---|---|---|
| You, on your own machine | You | Browser login |
| A pipeline or container | Your group | A Group token, supplied one of the two ways below |
If you configure CI/CD, use a Group token. If you run a scanner on your laptop, sign in through your browser. You do not have to use a token.
Authenticating as your group
A Group token is a credential for your group only. The command-line scanners of Fluid Attacks and the CI Gate use it. You can give it in two ways.
| Way to supply it | Best for | What you keep |
|---|---|---|
| Short-lived, via OpenID Connect | Any system that can mint OIDC tokens | Nothing — minted per job |
| Long-lived secret | Systems that cannot mint OIDC tokens | The Group token, as a secret |
Short-lived, via OpenID Connect (recommended)
Your CI/CD provider mints a short-lived, signed token for each job.
Your scan names its group with --group.
Fluid Attacks then makes sure that the token agrees with a trust that you define one time,
and gives your group access for that run.
You do not have to keep or rotate a secret.
Follow the OIDC federation guide to set it up.
Long-lived secret
If OIDC is not available,
generate a long-lived Group token and store it as a secret.
Generate it with the DevSecOps → Manage token flow of your group
(read
CI Gate configuration).
Then, give it to the scan as the INTEGRATES_API_TOKEN environment variable:
export INTEGRATES_API_TOKEN="<your-group-token>"
ss scan --strict .The scan uses the token only to identify the caller. The scan does not show the token or write it to logs.
For scanners delivered as Docker containers, pass --group inside the docker run command and hand the token to the container as an environment variable
(-e INTEGRATES_OIDC_TOKEN or -e INTEGRATES_API_TOKEN).
Which should I use?
- Running a scan yourself, on your own machine? Sign in through your browser. Nothing to store, and the run is attributed to you.
- Can your CI/CD system or runtime mint OpenID Connect tokens? GitHub Actions, GitLab CI, Azure DevOps, Kubernetes, and many others can. Use OIDC, because you do not have to keep a long-lived secret.
- If it cannot, keep a long-lived Group token as a secret.
The two group options authenticate the run in the same way. The only difference is if you keep a long-lived secret or not. A browser login is different: it authenticates you, not your group. If you also give a Group token, the scan uses the Group token.
A separate personal API token authenticates you to the GraphQL API, not a scan — see API basics.
What authenticating gets you
For the SAST, SCA, and secrets scanning CLIs, a run that resolves to a group also gets two policies of that group. They are the exclusions and the severity-breaking policy on the Fluid Attacks platform. The run applies them automatically. For more information, read Platform policy sync.
OWASP Benchmark results
Know about the Fluid Attacks scanner true positive rate of 100 on the OWASP Benchmark. A guide is included to reproduce the results in vulnerability detection.
Browser login
Sign in to the Fluid Attacks CLI through your browser, so scans on your own machine are attributed to you without storing a long-lived token.