If your miniapp has its own backend, session.auth lets you call it as the current Glassly user, with no login screen. The host hands your miniapp a signed token; your backend verifies it and gets the user’s id. Two steps.

Get started

1. Call your backend from the miniapp

Use session.auth.fetch exactly like fetch. It attaches the user’s token for you.
src/background/index.ts

2. Verify the token on your backend

Install @glassly/auth and add its middleware. The verified user lands on the request.
That’s it. Every request to /api/* now arrives with a verified Glassly user id, and a token minted for another miniapp can’t be used against yours (its audience is pinned to your package).

On the client

session.auth.fetch(input, init) is the easy path. If you bring your own HTTP client, grab the header or token instead:
The token rotates, so read it through fetch/getAuthHeader/getToken each time rather than caching the string. Those three take a minTtlMs option, the minimum lifetime the token must still have (default 30000); if the current token has less left, the call waits for the next refresh.
session.auth.current holds the active token and who it’s for (or null before the host issues one). session.auth.glasslyUserId and session.auth.oemId are getter shortcuts.

On your backend

createAuthService({ packageName }) checks the signature against GlasslyOS’s JWKS, the issuer, and the audience (your packageName), and rejects expired tokens. packageName can also come from the GLASSLY_PACKAGE_NAME environment variable. Not on Hono? Verify directly:
Each resolves to a VerifiedAuth (or throws AuthError):

Pointing at a non-production Core

By default it verifies against production Core’s JWKS (https://core.glassly.com/.well-known/jwks.json). For local, staging, or self-hosted Core, pass jwksUrl (or set GLASSLY_AUTH_JWKS_URL):