Docs / Reference
Tokens and lifetimes
| What | Lifetime |
|---|---|
| Authorization code | 1 minute, single use |
| Access token | 10 minutes |
| ID token | 1 hour |
| A sign-in in progress | 1 hour |
| Email sign-in link | 15 minutes, single use, only in the browser that asked for it |
| signo session | 14 days |
| A single-page app's refresh token | 14 days from sign-in, bound to its browser's key |
| Consent for a site | 1 year |
ID tokens
ID tokens are JWTs signed with RS256. The public key is at /jwks; libraries fetch it through discovery. v0.1 doesn't rotate the signing key on a schedule. If the key changes, libraries pick up the new one from /jwks on the next sign-in.
Access tokens
Access tokens are opaque strings that work at the userinfo endpoint (/me). Sites that only need to know who signed in can ignore them and read the ID token.
Refresh tokens: single-page apps only
Sites with a server get no refresh tokens. When a site's own session ends, it sends the person through sign-in again; while their signo session lasts, that takes no action from them.
Single-page apps get one with every sign-in, without asking for offline_access, so signo.js can keep a person signed in. Their tokens must be bound to a key the browser keeps (DPoP, RFC 9449), so a refresh token copied out of the browser is useless. Each lasts at most 14 days from sign-in and ends when the person signs out of signo in a browser where they used the app. Being useless when copied, it isn't replaced when used.
Signing out
The end-session endpoint (/session/end) ends the signo session and revokes the tokens of every site used in it, in all of the person's browsers, because consent, and the tokens issued under it, belong to the person and the site and so are shared by all their browsers. Consent stays, so the next sign-in skips the consent screen. Deleting the account removes everything, consents included.