Solutions Use case

Service-to-service and workload identity

A service on Kubernetes, a GitHub Actions job or a Lambda function already has an identity from its platform. LumoAuth accepts that identity and exchanges it for a short-lived token limited to one API. Where a secret is unavoidable, client credentials, mutual TLS and sender-constrained tokens keep it safe.

app.lumoauth.dev
Registering a workload identity binding for a cloud platform

Secrets in CI and config files are the leak that keeps happening

Long-lived client secrets get copied into pipelines, logs and laptops. Rotating them breaks things, so nobody does.

How LumoAuth solves it

Workload identity federation

AWS (IRSA), Azure, Google Cloud, Kubernetes projected tokens, SPIFFE, GitHub Actions, GitLab CI, CircleCI, Buildkite, Azure DevOps, Terraform Cloud, Cloudflare Workers, Vercel and any OpenID Connect issuer. Docs

Client credentials and JWT bearer

Standard OAuth for services that have a secret. Secrets are hashed at rest and rotated from the portal. Docs

Sender-constrained tokens

DPoP binds a token to the caller's key; mutual TLS binds it to a certificate. A copied token is useless elsewhere. Docs

One API per token

Resource indicators pin a token to a single audience, so the billing service cannot call the user service with it. Docs

Scoped API keys

For scripts and CI, keys with specific permissions and an expiry. Docs

app.lumoauth.dev
Scoped API keys

Kubernetes and Terraform

Create clients and agents from a Kubernetes Job, and keep configuration in version control with the Terraform provider. Docs

Setting it up

Register the workload

Pick the platform, paste the issuer and subject pattern (for example a GitHub repository and branch).

Exchange the platform token

The SDK or one HTTP call turns the platform's identity token into a LumoAuth token.

Call your API

The API validates the token against the published keys and checks the audience.

Standards involved

Plain names on the left, the specification on the right. The full map is in the standards reference.

JWT bearer and client authentication
RFC 7523
Token exchange
RFC 8693
Mutual TLS
RFC 8705
DPoP
RFC 9449
Resource indicators
RFC 8707
Workload identity
SPIFFE JWT-SVID

Standards reference on the docs site

Which plan you need

Client credentials, token exchange and scoped API keys are on every plan with a monthly allowance of machine-to-machine tokens (1,000 on Developer, 10,000 on Pro, 100,000 on Business, then a published per-token price). Cloud workload identity is a $99/month add-on on Pro and included in Business; GitHub Actions attestation is free on every plan. DPoP starts on Pro; mutual TLS is on Business.

See all plans and add-ons

Documentation

Questions

Is an agent the same thing as a workload?
In LumoAuth a workload identity is one way an agent (or a plain service) can authenticate. The agent registry tracks both.

Ship passwordless sign-in this week. Put guardrails on your agents today.

The Developer plan is free for 10,000 monthly users and ten agents, with no card. Everything speaks open standards, so moving in or out is a config change.