Hono on Deno Deploy

Real separate deployment

A confidential Auth0 client using @auth0/auth0-hono · deployed for real to Deno Deploy, not embedded in this app · same OIDC flow as Traditional/BFF and the Cloudflare Workers demo, but a third genuinely different runtime and dependency-resolution model

Try it on the real deployment

This runs on its own Deno Deploy deployment with its own Auth0 application — log in there for real, view the decoded claims and access token on its /dashboard, then log out.

Open the Hono/Deno demo
Same flow, different foundations
Traditional / BFF (this suite)Hono on Deno Deploy
RuntimeNode.js serverless (Vercel Functions)Deno isolate (Deno Deploy)
Session storageStateful — Firestore-backed SessionDataStore; cookie holds only an opaque session IDStateless by default — session data lives inside an encrypted cookie, no database
Revocation modelDelete the Firestore doc; Back-Channel Logout already wiredNo server-side record to delete by default — revocation means key rotation or a short TTL
SetupHand-rolled routes per pattern, using SDK primitives directlyOne middleware call — app.use('*', auth()) auto-mounts login/callback/logout/backchannel-logout
Dependency resolutionnpm install into node_modules, bundled by Next.jsnpm: specifiers in deno.json, resolved directly from the registry — no node_modules, no bundler
SDK@auth0/nextjs-auth0@auth0/auth0-hono

Same confidential-client model, same Authorization Code + PKCE flow underneath as both Traditional/BFF and the Cloudflare Workers demo — the teaching point here is that the dependency-resolution model is also a genuinely different axis: Deno resolves @auth0/auth0-hono straight from the npm registry via an npm: specifier, with no node_modules directory and no bundler step at all.

Architecture & Token Flow

Traditional / BFF (this suite)

Browser

Session cookie only

Vercel Function

Node.js, @auth0/nextjs-auth0

Firestore

Tokens + session state

Both

Auth0

Authorization Code + PKCE, same tenant/flow

Hono on Deno Deploy

Browser

Encrypted session cookie

Deno Deploy isolate

@auth0/auth0-hono via npm: specifier

— none —

No server-side session store

1Browser redirects to Auth0 Universal Login — identical for both runtimes.
2Auth0 redirects back with an authorization code to each runtime's own callback route.
3Traditional/BFF exchanges the code, writes tokens to Firestore, and hands the browser an opaque session-ID cookie.
4The Deno app exchanges the code via app.use('*', auth()), then encrypts the session data directly into the cookie — no database round trip, and no compatibility flag needed for the SDK's async_hooks usage (Deno's Node-compat layer handles it transparently, unlike Cloudflare's explicit nodejs_compat).
5Revoking access differs by design: Traditional/BFF deletes the Firestore doc and fires Back-Channel Logout. The Deno deployment, like the Workers one, has no server-side record to delete, so revocation means rotating the signing key or waiting out the cookie's TTL.
Security Implications

Strengths

  • Same self-contained encrypted-cookie session model as the Cloudflare Workers deployment — no database to provision, and the SDK's Node compatibility layer (async_hooks via AsyncLocalStorage) works with zero opt-in flags, unlike Workers' explicit nodejs_compat requirement.
  • The npm: specifier resolves @auth0/auth0-hono and its own dependency tree (jose, openid-client, oauth4webapi, zod) directly from the npm registry with no build step or bundler — Deno's own type-checker validated the whole chain cleanly on first try.
  • One middleware call (auth()) auto-mounts login, callback, logout, and backchannel logout, identical to every other auth0-hono deployment — the SDK's public surface doesn't change across runtimes even though the underlying compatibility shims do.

Risks & Considerations

  • Same fundamental gap as the Workers deployment: the default session mode has no server-side record to delete, so revocation means key rotation or waiting out the cookie TTL, not an on-demand kill switch.
  • authRequired defaults to true and protects every route unless told otherwise — the same easy-to-miss default documented on the Workers demo, reproduced here because it lives in the SDK, not the runtime.
  • npm: specifiers pull directly from the public registry at deploy time with no lockfile-style pinning enforced by deno.json alone — a supply-chain compromise of any package in the dependency chain (hono, jose, openid-client, oauth4webapi, zod) is a real risk shared with any npm-based deployment, not unique to Deno, but worth naming since this is the first demo in the suite to depend on npm: specifier resolution rather than a bundled node_modules tree.

Hardening Checklist

  • Keep session TTLs short in the default stateless mode — there is no kill switch, so lifetime is the primary control over exposure, same guidance as the Workers deployment.
  • Pin exact dependency versions in deno.json rather than caret ranges once this moves past a demo, to avoid an unreviewed transitive update landing on a production deploy.
  • Explicitly set authRequired: false for any route that should be public, and verify it — do not rely on the default matching your intent.