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
Usesession.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.
/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:
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:
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):

