GitHub OIDC Token
A github oidc token lets your workflow log in to cloud tools without saved passwords. The runner asks the identity provider for a short-lived signed token during the job. Teams set up this flow to stop pasting static keys into repo settings. Still, broad trust rules often let any branch or repo assume powerful cloud roles. Once a job logs in, that role can run wide commands across your systems. How a github oidc token works in workflows Every workflow run starts when an event triggers a job o
Token Rotation + GitHub Actions Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A github oidc token lets your workflow log in to cloud tools without saved passwords. The runner asks the identity provider for a short-lived signed token during the job. Teams set up this flow to stop pasting static keys into repo settings. Still, broad trust rules often let any branch or repo assume powerful cloud roles. Once a job logs in, that role can run wide commands across your systems.
How a github oidc token works in workflows
Every workflow run starts when an event triggers a job on a runner. If the job has token permissions enabled, the runner contacts the built-in identity provider. The provider builds a signed JSON Web Token for that specific job run. This github oidc token holds claims about the repo, branch, actor, and workflow name.
Next, the job sends this signed token to your cloud platform or target system. The target platform checks the signature against the public keys of the identity provider. It also checks the token claims against the trust policy you set up earlier. If the repo and branch match your rule, the cloud issues a short-lived role session.
Your workflow step then uses that temporary session to run tasks or deploy apps. When the job ends, the session expires on its own without manual cleanup. No person has to rotate a static secret or update stored repo keys.
Why teams replace static keys with federation
Long-lived cloud keys stored in repo settings create a constant risk for engineering teams. Anyone with admin rights in the repo might copy or misuse those saved keys. If a key leaks in a build log, attackers can use it from anywhere. Rotating those secrets across dozens of repos takes hours of manual work every month.
OpenID Connect federation fixes the storage problem by removing saved cloud secrets from repos. Tokens only exist while the workflow runs and expire shortly after the job starts. You can also lock down trust policies to specific branches, tags, or deploy stages. For example, you can allow production roles only when a job runs from main.
Token Rotation + GitHub Actions Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What identity federation leaves open during execution
Federation solves how a job logs in, but it stops at the front door. Once the cloud platform grants a role session, the token check is complete. The cloud role decides which services the runner can touch, not which commands are safe. A deploy job often needs broad write permissions to update databases or cluster resources.
If a bad script or pull request runs in that job, it shares that role. The workflow could drop a table or read raw emails, phone numbers, and card numbers. Cloud audit logs will show that the workflow role ran an API call. Yet they rarely tie individual database queries back to the exact workflow actor and step. Nor can a trust policy pause a single risky command mid-flight for human approval.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What claims are inside a github oidc token?
The token includes the repo name, branch or tag ref, commit SHA, and actor name. It also lists the workflow name and the target audience for the request. Your cloud trust rule checks these fields before it grants a session.
How do you stop fork pull requests from getting cloud roles?
Set your cloud trust rule to match the exact repo name and branch ref. Do not allow wildcard matches on the subject claim in your role policy. Also restrict workflow token permissions to read-only by default in your repo settings.
Does federation protect databases from destructive queries during a deploy?
No, federation only checks identity when the workflow first logs in to the cloud. After the job gets database credentials, it can run any query that database role allows. Controlling individual queries or masking card numbers and national IDs requires inspection during the session.