OIDC federation

Last updated: Oct 27, 2026

With OpenID Connect (OIDC) federation, your CI/CD pipelines can authenticate to Fluid Attacks without a stored long-lived secret. Your provider mints a short-lived, signed token for each job. Fluid Attacks makes sure that the token agrees with a trust that you define one time.

How it works

1. Your CI/CD provider issues a signed OIDC token for each job, describing the workflow that requested it (repository, project, or pipeline).
2. In your organization, you define a trust: the issuer to trust and the token claims that must match for a run to be accepted.
3. You enable the trust for the groups that must use it.
4. Your scan names its group with --group and presents the token. Fluid Attacks makes sure that the signature and claims are correct, and then authenticates the run as your group.

Set up a trust

In this example, GitHub Actions in the repository acme/web authenticates as the group acme-web. Use your own organization, group, and repository in each step. The issuer and claim names are different for each provider. If you use GitLab CI or Azure DevOps, get the values from Provider reference. You must have the Organization Manager role.

1. Open the federation settings

In your organization, go to Integrations, select the Programmatic access tab, and then Federation. Select Add trust to open the provider picker.

2. Choose your provider

Select GitHub Actions to pre-fill the GitHub Actions issuer and a recommended claim. Choose Manual / custom for a provider that is not listed.

3. Set the trust conditions

On the Trust conditions step, complete the fields and select Continue:

To trust all the repositories in your organization, not only one, use the claim repository_owner with value acme. For the full list of claims you can bind, see GitHub's OpenID Connect documentation.

4. Enable it for your group and create it

On the Group access step, select acme-web, and select Create trust. You must enable the trust for at least one group.

A trust applies only to the groups you enable it for. To change its conditions or groups later, select the trust in the list and use the Trust conditions and Group access tabs. Enabling or disabling it takes effect on the next run.

Trust requirements

The verifier enforces a safe configuration:

• The issuer must be an https URL that exposes a valid OpenID discovery document (/.well-known/openid-configuration) reachable without a redirect.
• Tokens must be signed with an asymmetric algorithm (RSA, ECDSA, or EdDSA). Unsigned tokens (none) and symmetric (HMAC) signatures are rejected.
• A trust must have one or more trust conditions. The verifier does not accept a trust with only an issuer. Thus, only your repositories can authenticate.
• By default, the token's audience (aud) must be https://app.fluidattacks.com. Providers that mint a fixed audience (such as Azure DevOps) set that value on the trust instead.

Provider reference

This section shows the values for step 3 for each supported provider, and the pipeline configuration that mints the token.

GitHub Actions

GitHub issues an OIDC token to any workflow granted the id-token: write permission. See GitHub's OpenID Connect documentation.

In your pipeline, grant the permission. ss requests the token automatically:

# .github/workflows/ss.yml
permissions:
  id-token: write
  contents: read
jobs:
  secretScan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: curl -fsSL https://public.fluidattacks.com/ss/install.sh | sh
      - run: ss scan --group my-group --strict .

In Fluid Attacks, add a trust with these values:

Bind repository to a single repository, or repository_owner to trust every repository in your organization.

GitLab CI

GitLab issues an OIDC token through the id_tokens keyword. See GitLab's ID token documentation.

In your pipeline, request a token with the Fluid Attacks audience:

# .gitlab-ci.yml
secretScan:
  image: ubuntu:latest
  id_tokens:
    INTEGRATES_OIDC_TOKEN:
      aud: https://app.fluidattacks.com
  script:
    - curl -fsSL https://public.fluidattacks.com/ss/install.sh | sh
    - ss scan --group my-group --strict .

In Fluid Attacks, add a trust with these values:

For a self-managed GitLab instance, set the issuer to your instance URL (for example, https://gitlab.example.com).

Azure DevOps

Azure DevOps issues an OIDC token through a workload identity federation service connection. See Microsoft's workload identity federation documentation.

In your pipeline, get the federation token from your service connection. Then, before the scan, set the INTEGRATES_OIDC_TOKEN environment variable to that token.

In Fluid Attacks, add a trust with these values:

Replace <organization-id> with your Azure DevOps organization GUID. Azure DevOps tokens carry the fixed audience api://AzureADTokenExchange, so the trust sets that value explicitly.

Other providers

Any provider that implements OpenID Connect can federate with Fluid Attacks. Choose Manual / custom when adding the trust and provide:

• the provider's issuer URL (https, with a reachable discovery document),
• one or more trust conditions (claims and their values) that scope the trust to your workloads, and
• the audience your provider mints, if it is not https://app.fluidattacks.com.

Then expose the provider's OIDC token to the scan as the INTEGRATES_OIDC_TOKEN environment variable.