GitHub Actions OIDC Token Lifetime Minutes
You cannot change the github actions oidc token lifetime minutes inside your workflow file. Instead, you set the session length on the cloud role that trusts the token. Teams use OpenID Connect to stop storing long-lived keys inside code repos. A job asks GitHub for a short identity token at run time. The job then swaps that token for a temporary cloud role session. If that cloud role has broad permissions, any bad script can abuse the session. How github actions oidc token lifetime minutes wo
GitHub Actions Security + Token Rotation: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You cannot change the github actions oidc token lifetime minutes inside your workflow file. Instead, you set the session length on the cloud role that trusts the token. Teams use OpenID Connect to stop storing long-lived keys inside code repos. A job asks GitHub for a short identity token at run time. The job then swaps that token for a temporary cloud role session. If that cloud role has broad permissions, any bad script can abuse the session.
How github actions oidc token lifetime minutes work
Every workflow run goes through two separate token steps during a job. First, the runner asks the GitHub identity provider for a signed JSON web token. This initial token has a fixed, short lifespan that users cannot edit. Its only job is to prove the workflow identity to an external cloud provider. The token holds claims about the repo, branch, and workflow name.
Second, the workflow sends this initial token to your cloud provider. The cloud provider checks the token signature and reads the workflow claims. If the claims match your trust rules, the cloud issues a temporary session token. When engineers ask about github actions oidc token lifetime minutes, they mean this second token. You control this timer inside your cloud role settings, not in GitHub.
Most cloud providers let you pick a session duration within a set range. You can set a short window for quick builds or a longer one for big tests. Your workflow login action can also ask for a shorter timer during the run. The cloud role sets the upper limit for that request. If the job runs longer than the session timer, later cloud calls will fail. Teams must either raise the role limit or request a fresh token mid-job.
What token timers solve and what they miss
Short token timers fix the big risk of leaked static keys. Old setups stored static cloud keys in repo secrets for months or years. Anyone who stole those keys could use them from any machine at any time. With OpenID Connect, the token dies soon after the build finishes. An attacker who grabs an expired token from build logs gets nothing.
Still, a short timer only limits when a session ends. It does not control what the job does while the token is active. Build jobs often need broad database or cluster permissions to run migrations and tests. During those active minutes, the runner holds full power for that cloud role. A bad third-party action or compromised build script can run destructive queries right away. It can drop tables or read raw customer emails, phone numbers, and card numbers.
GitHub Actions Security + Token Rotation: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Why role timers do not inspect live queries
Cloud role trust rules only check identity at the start of a session. Once the cloud issues a temporary credential, the identity check is over. The cloud role cannot look inside database queries or Kubernetes commands in flight. Also, native cloud logs only show that a generic build role logged in. They do not record the exact SQL statements or shell commands the runner sent.
To stay safe during active build minutes, teams need controls below the role level. You must inspect individual commands and queries after the job logs in. You also need data masking that rewrites matched fields like national IDs in results. This stops build logs from leaking sensitive data even when a token is valid.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Can I change the GitHub OIDC token expiration time directly?
No, GitHub sets a fixed lifespan on the initial identity token. You can only change the duration of the cloud session token that follows it.
Why did my workflow fail with an expired token error?
Your build step ran longer than the session duration allowed by your cloud role. You can increase the max session duration on the role or refresh credentials mid-job.
Does a short token lifetime protect databases during a build?
No, a short timer only cuts off access after the clock runs out. While the token is active, the job can run any query the role allows.