{
  "id": 10968960,
  "title": "OIDC: AWS OIDC Federation",
  "url": "https://urgent.news/2026/09/30/oidc-aws-oidc-federation",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-30T15:06:44.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/aleksandr_sorokin_devops/oidc-aws-oidc-federation-1op6"
  },
  "original_language": "en",
  "account": "In my previous articles, I touched on the critical concept of zero static credentials, which becomes increasingly significant as we engage with AI agents in secured environments, potentially exposing credentials inadvertently. This section delves into how to authenticate GitHub Actions jobs with the AWS API to provision AWS resources without employing static credentials.\n\nGitHub offers an OIDC provider for GitHub Actions, enabling repository, pull requests, and environments to function as identities for resource servers that accept OIDC tokens. A token example from the official documentation is provided as follows:\n\n{\n\"typ\": \"JWT\",\n\"alg\": \"RS256\",\n\"x5t\": \"example-thumbprint\",\n\"kid\": \"example-key-id\"\n}\n\nThe token includes a sub claim, which is the essential identifier for the token issuer. This identifier remains stable throughout the token's lifecycle and is usually the most reliable method to link a returning principal. The sub claim may differ based on whether the job operates against a reference, tag, pull request, or environment. The environment-specific subject claim incorporates the environment's name when the job targets an environment. The syntax for this is repo:ORG-NAME/REPO-NAME:environment:ENVIRONMENT-NAME. For instance, repo:octo-org/octo-repo:environment:Production denotes a production environment. If the workflow is not triggered by a pull request event and does not reference an environment, the subject claim includes the branch name. The syntax here is repo:ORG-NAME/REPO-NAME:ref:refs/heads/BRANCH-NAME. Additional information on this topic can be found in the official GitHub documentation.\n\nTo request a token, GitHub Actions offers an official action that simplifies the process of obtaining the token and configuring the AWS CLI to utilize it. The workflow begins with a name AWS example workflow, followed by the event on which it operates, in this case, a push. The environment is specified as AWS_REGION, and the role to assume is defined as ROLE-ARN. Depending on the job's scope, the permissions section can include actions such as id-token write and read, which are crucial for requesting the JWT contents and using the actions/checkout job, respectively. The run level steps include checking out the repository using actions/checkout@v6 with fetch-depth set to 0, configuring AWS credentials with aws-actions/configure-aws-credentials@v6.1.0, using role-to-assume and aws-region variables, and finally invoking aws sts get-caller-identity to retrieve the caller identity.",
  "summary": "Introduction In my previous posts, I briefly mentioned the important topic of zero static credentials. This is especially relevant today, as interactions with AI agents in protected environments can unexpectedly expose credentials. In this part, I explain how to authenticate my GitHub Actions jobs with the AWS API to provision AWS resources without static credentials. GitHub OIDC Provider GitHub…",
  "key_points": [
    "GitHub Actions OIDC provider authenticates GitHub jobs with AWS API",
    "Token includes sub claim as unique identifier for issuer",
    "aws-actions/configure-aws-credentials simplifies AWS CLI setup"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}