Frontend Auth
Register trusted JWKS so your own users can open sessions
Settings → Frontend Auth is where you register the external identity providers uRun
will trust when your users open sessions from the browser. It's the console twin of the CLI
command urun auth trust-jwk.
Why it exists
When you ship a frontend on uRun, your end users authenticate against your identity provider and present a JWT. uRun needs to know which provider to verify those JWTs against. You register that trust here, once, by pointing at the provider's JWKS.
The auth modes
| Mode | When | How uRun verifies |
|---|---|---|
| Scoped client token (recommended) | Your own server mints tokens for your browser users | Short-lived scoped tokens minted server-side from your org API key |
| WorkOS | You use WorkOS as your IdP | Short-lived WorkOS access tokens against your org's registered WorkOS JWKS — registered the same way as any customer-JWT provider, not a separate default path |
| customer-JWT | You bring your own JWTs | Your JWTs against the JWKS you register here |
Scoped client tokens (recommended)
The simplest browser auth path needs no IdP registration at all: your server mints a
short-lived, scoped client token from your org API key with createClientToken from
@urun-sh/core, and hands it to the browser. The org API key
never leaves your server, and the browser can only narrow the token's scope — never
widen it.
import { createClientToken } from "@urun-sh/core"
export async function POST() {
const { token, expiresAt, orgId } = await createClientToken(process.env.URUN_API_KEY!, {
allowedFunctions: ["my-app/generate"], // scope — the browser can only narrow this
allowedOrigins: ["https://myapp.example"],
maxSessionS: 600,
})
return Response.json({ token, expiresAt, orgId })
}This is the onramp path — right for prototypes and internal tools. Products with real end users should put an identity provider in front instead: see Production auth best practices.
What you register
For a customer-JWT provider you supply:
- The provider's JWKS URL (HTTPS).
- The expected issuer and audience.
This registers a trust relationship only — uRun never mints or stores your JWTs; your IdP
issues them, and uRun verifies them. Identity is always read from the token's sub and
email claims — custom claim-name mapping is not yet supported end-to-end.
When to use it
- Wire customer-JWT auth so end users sign in with your own login.
- Manage or rotate the trusted providers for your org.
See the TypeScript SDK for how the browser client passes orgId
plus a user JWT, and urun auth trust-jwk for the terminal
equivalent of this page.
Frontend Auth is the correct way to authenticate browser users. Never ship the org deploy API key or any long-lived secret to the browser.