Ngl, one of the easiest ways to make a deployment pipeline sketchy is to give it a long-lived storage token and hope nobody ever leaks it.
That pattern is still everywhere: CI uploads static assets, build artifacts, screenshots, or user-facing files to some blob bucket, and the workflow stores a token in secrets.BLOB_TOKEN forever.
It works.
It also quietly creates a key that can outlive the job, the branch, the intern who created it, and sometimes the entire project. Big yikes.
The better pattern that keeps showing up across modern platforms is OIDC-based deploy auth: your CI job proves who it is, asks the provider for short-lived access, does the upload, and disappears.
The old flow
Most teams start here:
- name: Upload assets
env:
BLOB_TOKEN: ${{ secrets.BLOB_TOKEN }}
run: npm run upload-assets
Simple, but the risk is obvious:
- the token sits in your repo/org secrets forever
- rotation becomes another chore nobody owns
- leaked logs, compromised runners, or copied workflows can turn into real access
- every workflow tends to get more permission than it actually needs
For a side project, maybe that feels acceptable. For production pipelines, it becomes tech debt with security vibes.
The OIDC flow
With OIDC, GitHub Actions or another CI provider can request an identity token for the current job. The cloud/storage platform verifies claims like repo, branch, environment, and workflow, then issues temporary credentials.
The workflow shape becomes closer to this:
permissions:
id-token: write
contents: read
jobs:
upload:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Upload assets with short-lived auth
run: npm run upload-assets
The actual provider setup differs, but the idea is the same: trust the workload identity, not a copied secret string.
This is why recent platform updates around OIDC for blob/storage workflows are worth paying attention to. They are not just “nice auth features.” They are a signal that deployment secrets are moving from static keys to verified, short-lived identity.
Why developers should care
This is not only a security-team thing.
OIDC makes day-to-day engineering cleaner:
- fewer secrets to create, share, rotate, and audit
- safer preview deployments from protected branches or environments
- tighter permissions per repo/workflow instead of one mega-token
- less panic when someone accidentally prints an env var in CI
Tbh, the best security improvements are the ones that remove a thing you had to remember. OIDC does exactly that.
A quick migration checklist
If your build uploads anything to blob storage, artifact storage, package registries, or cloud buckets, check this:
- Is the workflow using a long-lived token?
- Does the provider support OIDC or workload identity federation?
- Can access be scoped by repo, branch, workflow, or environment?
- Can the token be removed after the OIDC path works?
Do not migrate everything in one heroic PR. Pick one low-risk upload job, move it to OIDC, and document the pattern for the next workflow.
The takeaway
Long-lived deploy tokens were convenient when CI/CD was simpler.
But now that pipelines publish assets, trigger releases, talk to AI services, and touch production infra, “just store a token” is starting to look outdated.
If a platform gives you OIDC for deploy-time storage access, use it. Your future self will have one less secret to babysit — and that is a clean W.
Top comments (4)
Hey,
Really enjoyed this quick read. The "big yikes" of finding an ancient static token hanging around in a repo is too real.
I’ve actually been moving some of our deployment pipelines over to OIDC recently — mostly GitHub Actions pushing via Docker and Vercel, plus some GCP/Firebase infrastructure. Setting up Workload Identity Federation on Google Cloud felt like a bit of a chore the very first time I did it, but the peace of mind knowing there aren't any long-lived service account JSONs or blob tokens sitting in GitHub Secrets is 100% worth the initial friction.
Also, I completely agree with your advice at the end: do not migrate everything in one heroic PR. Taking it one low-risk upload job at a time is honestly the only way to keep your sanity during the transition.
Thanks for pushing this pattern. The more people talk about it, the sooner we can kill static deploy secrets for good.
Thank you 🙏
Hi, I hope you are doing well. We are a software development team. We hunt for US jobs using Us job profile. So we are looking for a senior developer who can work with us.
Your role is to take part in the job interviews and pass the interviews. If your English is fluent, we can work together. If you are interested, please kindly send me message. I will explain more detail. Thank you!
Whatsapp: +1 (351) 234-6532
Telegram: @lionking06230810
Sure I will let you know..!