6.2.2.17 RefreshToken
6.2.2.17.1 Purpose¶
One link of a refresh token chain. A sign-in starts a chain; every refresh rotates the token and adds a link with a new expiry, sliding over thirty days; the reuse of a rotated token revokes the whole chain, because only someone who copied an old token can still hold it. Only the hash of a token is stored, and access tokens are never stored at all: they last fifteen minutes and are verified by their signature.
6.2.2.17.2 Questions it answers¶
- Which sign-ins does this user have open, for which Organization and client?
- Why and when was a chain revoked?
- Was a rotated token used again?
6.2.2.17.3 Fields¶
| Field | Type | Cardinality | Description |
|---|---|---|---|
id |
string (uuid) |
1..1 |
Key. |
chain_id |
string (uuid) |
1..1 |
The sign-in the chain started from; revoking a chain ends every token of that sign-in. |
token_hash |
string |
1..1 |
Unique. SHA-256 of the token; the token itself is never stored. |
user |
Person | 1..1 |
|
organization |
Organization | 0..1 |
The active Organization the tokens are issued for; empty for a user with no Organization (User). One of the person's own Organizations, through a DirectMembership or a user group, never one they reach only through a delegation. A person with more than one chooses it in every app after signing in, and the app remembers the last choice; its type tells the app what to show. |
audience |
string |
1..1 |
The client id the chain belongs to, e.g. moonitoring-dashboard or moonitoring-farm-sync: a token is refreshed only for that client. |
issued_at |
datetime |
1..1 |
|
expires_at |
datetime |
1..1 |
Thirty days after issued_at; sliding: every rotation issues a new link with a new expiry. |
rotated_at |
datetime |
0..1 |
|
revoked_at |
datetime |
0..1 |
|
revoked_reason |
enum | 0..1 |
Values: sign_out, reuse_detected, membership_revoked, organization_closed, staff_action. |
6.2.2.17.4 Relationships¶
References
RefreshToken.user→ Person (1..1)RefreshToken.organization→ Organization (0..1)
6.2.2.17.5 Rules & constraints¶
- One link of a refresh token chain, as interface decision D15 describes it: a sign-in starts a chain, every refresh rotates the token and adds a link, and the reuse of a rotated token revokes the whole chain, because only a thief can hold an old token. Access tokens are never stored; they live fifteen minutes and are verified by signature.
- A link is deleted 30 days after it expired or was revoked; the audit and the sign-in log keep the history.