Correct and Still Broken: A GitHub OIDC Story

Kishan Patel — Thu, 24 Sep 2026 13:31:10 +0000

The Moment It Broke

"Welcome to my static site"! These words were like music to my eyes after I set up the AWS backend to host my static HTML website. Excited, I created the basic blog site with Astro and configured CI/CD in deploy.yml to start the deployment process and guess what came up!... "Welcome to my static site!" Something was wrong...

How I Debugged The Issue

I opened up my browser's console to debug if there were any errors, none. I cleared my cache, still my static site showed up. Then I went one level up, I checked in my S3 bucket, it wasn't there... my site never made it to S3. So, I went one more level above, my GitHub actions, and there it was Error: Could not assume role with OIDC: Not authorized to perform sts:AssumeRoleWithWebIdentity. I then went back to the AWS console and made sure I had github-deploy-site which was added from Terraform, to rule out Terraform Drift. Next I wanted to see what GitHub was actually sending, so I added a debug step right before the credentials step:

- run: echo "${{ github.repository }} / ${{ github.ref }}"

It printed Nasheik/KishanBuilds and refs/heads/main. Exactly what my trust policy expected. It was all correct, and at the time I did not realize that those two variables are not the sub claim. It was only after I asked Claude for help that I was pointed to a GitHub changelog from April 2026 that I hadn't found on my own. The subject portion of GitHub tokens had changed!

Part of what made this take so long is that the error tells you almost nothing. The same message covers a genuinely mismatched claim, a missing permissions: id-token: write block so no token is ever minted, and the format change I hit. Three unrelated problems at three different layers, one identical string.

The OIDC Process

When I push to the main branch, GitHub mints a short-lived JSON Web Token for each workflow run. It only exists for that run. The three claims that matter in this token are:

iss — the issuer, GitHub.
aud — the audience, sts.amazonaws.com.
sub — the subject, The repo and branch the workflow is running on.

The main part is the subject. The IAM role's trust policy has a condition on that sub string and gets used by STS to compare, if they do not match we get the error I got before. If they do match, you get the temporary credentials required to move forward, or, as in my case, upload files to S3 bucket.

The Change GitHub Made

"Repos created after July 15, 2026 get the new sub format by default." This was it, one line I found after Claude pointed me in the right direction. Source: https://github.blog/changelog/2026-04-23-immutable-subject-claims-for-github-actions-oidc-tokens/

Old: repo:OWNER/REPO:ref:refs/heads/BRANCH
New: repo:OWNER@OWNER-ID/REPO@REPO-ID:ref:refs/heads/BRANCH

What my trust policy expected:
repo:Nasheik/KishanBuilds:ref:refs/heads/main

What GitHub actually sent:
repo:Nasheik@MY-OWNER-ID/KishanBuilds@MY-REPO-ID:ref:refs/heads/main

This was made to prevent someone from inheriting your trust policy. Because the old format is just names, if you abandon your repo, someone else could claim and reproduce that sub string. With this change, that is not possible as your ID and your repo's ID are embedded into it.

The Fix

The fix for this was rather simple: change this condition

condition {
  test     = "StringEquals"
  variable = "token.actions.githubusercontent.com:sub"
  values   = ["repo:${var.github_repo}:ref:refs/heads/main"]
}

condition {
  test     = "StringEquals"
  variable = "token.actions.githubusercontent.com:sub"
  values = [
    "repo:${var.github_repo}:ref:refs/heads/main",
    "repo:${split("/", var.github_repo)[0]}@${var.github_owner_id}/${split("/", var.github_repo)[1]}@${var.github_repo_id}:ref:refs/heads/main",
  ]
}

This accepts either format for this specific repo, so I'm covered whichever way GitHub sends it, but the IDs are pinned, so a different repo would need its own values.

What It Taught Me

This tiny bug taught me two different lessons at once. First one, tutorials have timestamps, especially in a field like tech where everything changes so rapidly. You have to continuously learn, break, and re-learn. Second, when it comes to using different services, issues often stem from what one service sends and what the other service expects to receive, which is exactly what I thought my debug step was doing. Double checking that bridge will help catch bugs faster, as long as you're checking the real thing and not something that resembles it.

What's Next

Next up: moving Terraform itself into CI. Right now my site deploys through Actions while my infrastructure gets applied from my laptop, which means the only record of what exists in AWS is a file on my machine. Fixing that means remote state, a plan step on every PR, and working out how a pipeline gets permission to manage the very role it's authenticating with, a problem that starts looking a lot like the one mentioned in this post.

Terraforming a Blog: The Setup

Kishan Patel — Fri, 11 Sep 2026 12:25:20 +0000

Why engineer something when you can overengineer it?

As I am just getting back into cloud, I looked up many different videos and articles about how I should learn cloud engineering. The first one that caught my eye was to start a blog site. There are tons of good options to start a blog with, but I decided why not try to create one myself as an initial project. I also hate writing and never know what to write about, so I figured building the project first would give me something to actually write about. Anddd that's what this is!

The Stack

Github - Allows for version control and CICD pipeline via Actions
Terraform - Allocate Resources needed to Run my website
AWS - Backend Terraform allocates resources from
- S3 - Where my website is hosted as well as Terraform State
- CloudFront - Content Distribution for my website
- ACM - TLS Certification for CloudFront
- Route 53 - DNS and Domain
- AWS Budgets for cost alerts
- IAM - Defines exactly what each identity is allowed to do
  - SSO - Gives me temporary access to run Terraform locally via CLI, nothing stored
  - OIDC - Gives GitHub Actions temporary access to push site to S3, nothing stored

Deployment Pipeline

After pushing to my GitHub's main branch, GitHub Actions trigger. The actions trigger an npm run build which creates dist/ output which will be pushed to the website's S3 bucket. When syncing to S3, assets are stored, cached, and immutable - On the other hand html is stored, but not cached, so if I decided to add another blog, the html doesn't get stuck and show old pages on the website. After that, I look up the CloudFront distribution ID and invalidate everything there, so CloudFront, the content distributor, doesn't get stuck sending old copies of the website.

Why should you care?

This may not be for those who are less interested in tech and just want something up and running asap. This set up requires understanding of cloud but does give it to you in the process of creation. The ultimate upside is the control, free tier managed services only go so far, then the next tier requires payment. At some point you will hit your limit then have to spend to push the limits further out. That said, there is a reason they charge for their services, there's a lot that I have not covered about security and dynamic sites here.

What's Next

This is just the beginning. I have set up my blog website using Terraform, I plan to improve on the site itself while blogging about it. My next blog will go into further detail about the OIDC bug I encountered and how I fixed it. This is to teach and to learn. What I did may be helpful to you, but it definitely will be helpful for me! Happy Learning!

DEV Community: Kishan Patel

Correct and Still Broken: A GitHub OIDC Story

The Moment It Broke

How I Debugged The Issue

The OIDC Process

The Change GitHub Made

The Fix

What It Taught Me

What's Next

Terraforming a Blog: The Setup

Why engineer something when you can overengineer it?

The Stack

Deployment Pipeline

Why should you care?

What's Next