docs
Dashboard

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

ModeWhenHow uRun verifies
Scoped client token (recommended)Your own server mints tokens for your browser usersShort-lived scoped tokens minted server-side from your org API key
WorkOSYou use WorkOS as your IdPShort-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-JWTYou bring your own JWTsYour JWTs against the JWKS you register here

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.

app/api/urun-token/route.ts (any server runtime)
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.

On this page