🔒 OpenID Connect (OIDC) authentication for cloud services

Changelog Website
1

Bitrise builds can now integrate with cloud services more securely via the OpenID Connect protocol (OIDC).

We added three new steps which allow your builds to authenticate with cloud platforms like AWS, GCP, Azure and many more, using OIDC. This enables short-lived, tightly scoped credentials for build-time access to cloud resources — and removes the need to embed long-lived static credentials in your CI configuration.

:light_bulb: Why this matters

Many CI workflows need to interact with cloud services like AWS, GCP and Azure. Until now, integrating Bitrise with these services involved embedding long-lived service credentials in your CI config — increasing the risk of accidental exposure or misuse. OIDC gives you dynamic, short-lived tokens and fine-grained control over what a build can do, reducing the risk of credential compromise and simplifying compliance for security-conscious teams.

:flexed_biceps: Key benefits

  1. Enhanced security

    • Uses short-lived, dynamic credentials to reduce exposure of secrets.

    • Better suited for customers with strict compliance or audit requirements.

  2. More control

    • You define exact permissions in your cloud provider’s identity federation policy (e.g. “allow uploads to S3 bucket X during workflow Y”).

  3. Less maintenance

    • Eliminates the need to manually rotate credentials in your Bitrise config

:thinking: When to use it

Use the new steps whenever you need to interact in any way with a cloud platform that supports OIDC. This feature will particularly appeal to those organisations with strict security requirements.

Here are some examples of activities you might wish to perform securely with a cloud platform during a Bitrise build:

Mobile apps

  • Save build artifacts to S3 or GCS

  • Access secrets from a vault during builds

  • Interact with Firebase / Play Console or other release management systems

Web aps

  • All the use cases above

  • Manage private container images and push/pull to registries (ECR, GCR)

  • Deploy web apps to PaaS (Vercel, Heroku, DigitalOcean) or Kubernetes platforms

  • Deploy to managed services (Elastic Beanstalk, EKS, GKE, AKS)

:gear: How to set it up

For a full explanation of how OIDC works and step by step instructions for setting up your workflows, please refer to our Devcenter Guide. At a high level, the steps are:

  1. Configure identity federation/role in your cloud provider (we have detailed guides for AWS and GCP).

  2. Add the appropriate Bitrise OIDC authentication step to your workflow:

  3. Update your workflow to perform the desired actions in the cloud (e.g. upload to S3, push to ECR, deploy to GKE). You can use Bitrise steps like Amazon Web Services (AWS) S3 Upload and Google Cloud Storage Upload or a script step for this.

:brain: Good to know

  • If your builds already authenticate with cloud providers via a traditional access token, they will keep on working - you don’t need to change your Bitrise CI config unless you want to take advantage of the more secure OIDC protocol

  • Bitrise only facilitates token issuance and authentication during builds. The permissions are all configured in your cloud provider, which gives you granular control of what a build can do and when it can do it

If you’re serious about security, start using the new Bitrise authentication steps today. Happy building! :building_construction: