Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Use when a val needs to require login with a Val Town account — gating routes behind authentication, identifying the current user, building user-specific dashboards. Covers std/oauth's `oauthMiddleware` and `getOAuthUserData`, the auto-managed `/auth/*` routes, and session behavior. For third-party OAuth providers (Google, GitHub, etc.) see the `third-party-integrations` skill instead.
.claude/skills/hashgraph-online-oauth/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-01 | ✗→✓ | ▲ Improved | -48% | 0% |
| case-02 | ✗→✓ | ▲ Improved | -19% | 0% |
| case-03 | ✗→✓ | ▲ Improved | -40% | 0% |
| case-04 | ✗→✓ | ▲ Improved | -28% | 0% |
| case-05 | ✗→✓ | ▲ Improved | -30% | 0% |
Val Town provides zero-config "Log in with Val Town" via std/oauth. No database setup, no provider config — wrap your Hono fetch handler and you get login, logout, and session management for free. Sessions are stored in encrypted cookies and last 30 days.
This is for Val Town account login only. For Google / GitHub / Slack / etc. OAuth, see the third-party-integrations skill — those flows are documented per-service.
If the goal is to keep an app internal to a team rather than to give it its own logged-in users, restricting the val's app access is the simpler answer — the platform gates the endpoint before your code runs, and you write no auth code. See the restricted-access skill. Don't apply both to one val: a restricted val that also runs oauthMiddleware makes visitors authenticate twice.
tsimport { getOAuthUserData, oauthMiddleware, } from "https://esm.town/v/std/oauth/middleware.ts";
oauthMiddleware(handler) takes your Hono fetch handler and returns a wrapped handler that injects three auto-managed routes:
GET /auth/login — starts the login flowGET /auth/callback — completes the login flowPOST /auth/logout — clears the sessionExport the wrapped handler as the val's default:
tsimport { Hono } from "npm:hono"; import { oauthMiddleware } from "https://esm.town/v/std/oauth/middleware.ts"; const app = new Hono(); app.onError((err) => Promise.reject(err)); app.get("/", (c) => c.text("hello")); export default oauthMiddleware(app.fetch);
You don't write the /auth/* routes yourself — the middleware adds them. Don't shadow them in your own app.
Call getOAuthUserData(rawRequest) from any route. In Hono, rawRequest is c.req.raw. It returns the session data if the request is authenticated, or null otherwise.
tsinterface SessionData { user: { id: string; username: string | null; email: string | null; bio: string | null; tier: "free" | "pro" | null; type: "user" | "org"; url: string; links: { self: string; profileImageUrl: string | null; }; }; accessToken: string; // Val Town API token (act on behalf of the user) refreshToken?: string; idToken?: string; expiresAt: number; // Unix timestamp (ms) isOrgMember?: boolean; // true if user belongs to this val's org }
tsapp.get("/", async (c) => { const session = await getOAuthUserData(c.req.raw); if (session?.user) { return c.html( `<p>Logged in as ${session.user.username}</p>` + `<form method="POST" action="/auth/logout"><button>Log out</button></form>` ); } return c.html(`<a href="/auth/login">Log in with Val Town</a>`); });
There's no built-in "require login" helper — gate routes by checking getOAuthUserData and returning a 401 or redirecting to /auth/login when the session is missing:
tsapp.get("/dashboard", async (c) => { const session = await getOAuthUserData(c.req.raw); if (!session?.user) return c.redirect("/auth/login"); return c.html(`<h1>Welcome ${session.user.username}</h1>`); });
/auth/callback is wired automatically.After adding OAuth, call fetch_val_endpoint on a gated route to confirm it redirects or 401s when unauthenticated. The full login flow requires a real browser session and can't be exercised by fetch_val_endpoint alone — share the live URL and have the user try logging in.
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→pass | 36,126 | 15,699 | -57% | 1 | 1 | 0% | 6,682 | 3,460 | -48% | 0 | 0 | — |
case-02 | fail→pass | 19,168 | 13,823 | -28% | 1 | 1 | 0% | 3,883 | 3,148 | -19% | 0 | 0 | — |
case-03 | fail→pass | 27,932 | 6,099 | -78% | 1 | 1 | 0% | 4,069 | 2,450 | -40% | 0 | 0 | — |
case-04 | fail→pass | 33,494 | 7,347 | -78% | 1 | 1 | 0% | 1,836 | 1,313 | -28% | 0 | 0 | — |
case-05 | fail→pass | 35,174 | 3,369 | -90% | 1 | 1 | 0% | 2,517 | 1,758 | -30% | 0 | 0 | — |
case-06 | fail→pass | 7,525 | 7,322 | -3% | 1 | 1 | 0% | 1,257 | 1,398 | +11% | 0 | 0 | — |
case-07 | pass→pass | 10,070 | 2,183 | -78% | 1 | 1 | 0% | 1,642 | 1,334 | -19% | 0 | 0 | — |
case-08 | fail→pass | 13,777 | 5,848 | -58% | 1 | 1 | 0% | 2,229 | 1,532 | -31% | 0 | 0 | — |
case-09 | fail→pass | 28,647 | 8,359 | -71% | 1 | 1 | 0% | 1,940 | 1,507 | -22% | 0 | 0 | — |
case-10 | pass→pass | 39,508 | 7,776 | -80% | 1 | 1 | 0% | 2,041 | 1,466 | -28% | 0 | 0 | — |
case-11 | fail→pass | 20,124 | 33,705 | +67% | 1 | 1 | 0% | 2,887 | 2,202 | -24% | 0 | 0 | — |
case-12 | fail→pass | 18,743 | 12,973 | -31% | 1 | 1 | 0% | 2,434 | 1,957 | -20% | 0 | 0 | — |
case-13 | fail→pass | 13,394 | 7,526 | -44% | 1 | 1 | 0% | 1,241 | 1,468 | +18% | 0 | 0 | — |
case-14 | fail→pass | 17,023 | 9,694 | -43% | 1 | 1 | 0% | 2,097 | 1,841 | -12% | 0 | 0 | — |
case-15 | pass→pass | 11,722 | 3,422 | -71% | 1 | 1 | 0% | 1,786 | 1,474 | -17% | 0 | 0 | — |
case-16 | fail→pass | 17,116 | 4,704 | -73% | 1 | 1 | 0% | 1,801 | 1,620 | -10% | 0 | 0 | — |
case-17 | fail→pass | 16,391 | 7,215 | -56% | 1 | 1 | 0% | 2,570 | 2,097 | -18% | 0 | 0 | — |
case-18 | pass→pass | 17,299 | 2,993 | -83% | 1 | 1 | 0% | 2,001 | 1,262 | -37% | 0 | 0 | — |
case-19 | pass→pass | 25,008 | 8,332 | -67% | 1 | 1 | 0% | 2,481 | 1,623 | -35% | 0 | 0 | — |
case-20 | pass→pass | 17,116 | 3,924 | -77% | 1 | 1 | 0% | 3,458 | 1,637 | -53% | 0 | 0 | — |
case-21 | fail→pass | 33,661 | 9,112 | -73% | 1 | 1 | 0% | 2,689 | 2,226 | -17% | 0 | 0 | — |
case-22 | fail→pass | 126,305 | 22,051 | -83% | 1 | 1 | 0% | 3,255 | 2,938 | -10% | 0 | 0 | — |
case-23 | fail→fail | 134,643 | 39,536 | -71% | 1 | 1 | 0% | 1,988 | 2,170 | +9% | 0 | 0 | — |
case-24 | fail→pass | 273,429 | 85,337 | -69% | 1 | 1 | 0% | 2,759 | 2,608 | -5% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 24 cases were attempted. The headline lift of +71 percentage points is the difference between those two pass rates over the 24 comparable cases.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.