Authenticating to third-party systems

Most workflows need to talk to external platforms. You can authenticate in two primary ways:

• Static credentials (API keys, long-lived access keys) stored as encrypted secrets. Easy to integrate but riskier if they leak.
• OIDC federation where GitHub mints a short-lived JSON Web Token at runtime that a cloud provider exchanges for temporary credentials. This removes the need to manage secrets and sharply limits blast radius.

AWS is a good example because it supports both methods. After creating an IAM user you can place its access keys in repository secrets and feed them to the official AWS configure action:

jobs:
  # ❌ PLEASE DO NOT USE THIS APPROACH!
  auth-to-aws-static:
    runs-on: ubuntu-24.04
    steps:
      - name: "Configure AWS Credentials using static key"
        uses: aws-actions/configure-aws-credentials@7474bc4690e29a8392af63c5b98e7449536d5c3a # v4.3.1
        with:
          aws-region: us-east-2
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

The preferred alternative is to register GitHub's OIDC provider in IAM, create a role with a trust policy that allows your repository to assume it, and then request that role inside the workflow.

Don't forget to opt into id-token: write permissions so the runner can request the token.

  # ✅ PLEASE USE THIS APPROACH INSTEAD!
  auth-to-aws-oidc:
    runs-on: ubuntu-24.04
    permissions:
      id-token: write # This is required for requesting the JWT for OIDC auth to AWS
    steps:
      - name: "Configure AWS Credentials - Action for GitHub Actions"
        uses: aws-actions/configure-aws-credentials@7474bc4690e29a8392af63c5b98e7449536d5c3a # v4.3.1
        with:
          aws-region: us-east-2
          role-to-assume: arn:aws:iam::917774925227:role/github-actions-role

OIDC keeps credentials short-lived, enables granular scoping by repository or branch, and eliminates the operational overhead of rotating long-lived secrets.