David Dal Busco, founder of Juno, has outlined a new GitHub Actions integration that replaces long lived secrets with short lived tokens, aiming to tighten deployment security for applications running on the Internet Computer.
The update allows developers to deploy frontends and publish serverless functions from GitHub Actions using ephemeral access keys generated through an OpenID Connect flow. Rather than storing static credentials inside continuous integration pipelines, the workflow generates a short lived JSON Web Token that proves where the job is running, including the repository, branch and actor.
Authenticating CI pipelines without permanent secrets is not new. GitHub has supported OpenID Connect for some time. What makes this implementation different is the environment on the receiving end. Juno applications run inside Rust WebAssembly containers, referred to as Satellites, on a public blockchain. That means secrets cannot be handled in the same way they would be on a traditional server.
Under the new flow, a GitHub Actions workflow first generates an identity made up of a key pair and a cryptographic nonce derived from a salt and the identity’s public key. The workflow then exchanges that nonce with GitHub’s token endpoint to obtain a signed JWT. Because GitHub allows limited customisation of token fields, the nonce is passed via the audience claim.
The JWT and salt are sent to the Satellite using the generated identity. On the Rust side, the Satellite decodes the JWT header to identify the provider and retrieves the relevant public keys, either from cache or from Juno’s Observatory infrastructure, which maintains up to date OpenID Connect key sets.
Verification involves several checks. The JWT signature is validated against the provider’s keys. The issuer must match a configured provider. The nonce is reconstructed on chain using the same algorithm as in the workflow and compared with the claim in the token. Timestamps are checked against a strict ten minute validity window based on the issued at field, rather than relying on the token’s expiry value. A unique token identifier is recorded to prevent replay attacks.
If the checks pass, the identity is registered as a temporary controller on the Satellite, effectively acting as an ephemeral access key for the remainder of the workflow. A cleanup step removes the key once the job completes, regardless of success or failure.
Dal Busco has structured the implementation in layers. Core verification logic remains generic, while repository and branch checks are applied through a callback that asserts whether the incoming workflow matches what the developer has configured. This separation allows the same validation mechanisms to be reused for other authentication flows.
The Observatory component plays a practical role. Since OpenID Connect public keys are shared across all users of a provider, Juno centralises the task of fetching and caching those keys. A recurring timer retrieves JSON Web Key Sets from provider endpoints and stores them for Satellites to reference. If a fetch fails, for example during key rotation, the system retries with exponential backoff. This avoids excessive outbound requests and helps manage costs on the network.
Security engineers generally favour short lived credentials over static secrets, especially in CI environments where logs, environment variables and configuration files can become leak points. At the same time, introducing blockchain based verification and replicated HTTPS outcalls adds architectural complexity. Developers will need to weigh the benefits of stronger cryptographic guarantees against operational overhead and learning curve.
Dal Busco acknowledges that the flow involves many moving parts. His approach reflects a broader trend in cloud and blockchain infrastructure, where identity and authentication are increasingly tied to verifiable claims rather than stored passwords or tokens.
For teams deploying on the Internet Computer, the integration offers a way to align GitHub’s native OpenID Connect capabilities with Juno’s on chain execution model. Whether it becomes a default pattern for Web3 deployments may depend on how easily developers can adopt it and how clearly the security advantages translate into day to day practice.
Dear Reader,
Ledger Life is an independent platform dedicated to covering the Internet Computer (ICP) ecosystem and beyond. We focus on real stories, builder updates, project launches, and the quiet innovations that often get missed.
We’re not backed by sponsors. We rely on readers like you.
If you find value in what we publish—whether it’s deep dives into dApps, explainers on decentralised tech, or just keeping track of what’s moving in Web3—please consider making a donation. It helps us cover costs, stay consistent, and remain truly independent.
Your support goes a long way.
🧠 ICP Principal: ins6i-d53ug-zxmgh-qvum3-r3pvl-ufcvu-bdyon-ovzdy-d26k3-lgq2v-3qe
🧾 ICP Address: f8deb966878f8b83204b251d5d799e0345ea72b8e62e8cf9da8d8830e1b3b05f
Every contribution helps keep the lights on, the stories flowing, and the crypto clutter out.
Thank you for reading, sharing, and being part of this experiment in decentralised media.
—Team Ledger Life
Community Discussion