API OIDC for Umbraco
Let frontends call the Umbraco Delivery API and your own endpoints with their platform's OIDC token, instead of a shared API key.
A private Delivery API is protected by a single API key. Every frontend shares it, and rotating it means updating every project at the same time. Most hosting and CI platforms can instead give each workload a short-lived token, signed by the platform, that says which project or repository it came from. This package lets Umbraco accept those tokens on the Delivery API and on your own endpoints.
- Tokens expire on their own, so there is no secret to store or rotate.
- You choose which Vercel teams or projects, GitHub repositories or other workloads are allowed. Tokens from anywhere else are refused.
- Public access, media access and the API key work as before, so you can move frontends over one at a time and remove the key after the last one.
Supported platforms
| Platform | How the frontend gets a token | Setup |
|---|---|---|
| Vercel functions and builds | getVercelOidcToken() from @vercel/oidc |
Vercel preset |
| GitHub Actions | core.getIDToken(audience) |
GitHubActions preset |
| Google Cloud Run, Functions and GKE | The metadata server, with your audience | Custom issuer |
| AWS Lambda, ECS and EC2 | STS GetWebIdentityToken (IAM outbound identity federation) |
Custom issuer |
| GitLab CI | id_tokens in .gitlab-ci.yml |
Custom issuer |
| Azure | A managed identity token from Entra ID | Custom issuer |
Cloudflare Workers and Netlify Functions have no built-in workload token, so frontends there keep using the API key.
Requirements
- Umbraco CMS 17.1 or later, Umbraco 18 included, on .NET 10.
- A platform that gives your frontend an OIDC token. The table above lists the common ones.
Where to go next
- Quickstart installs the package and sends the first token.
- Issuers sets up Vercel, GitHub Actions and any other issuer.
- Custom endpoints protects your own controllers and minimal APIs.