The audit trail
Every issuance, refusal, revocation and console change on a topic the store refuses to rewrite, kept for 400 days, and read in order from the console.
Every outcome at the token and revocation endpoints, and every refusal at the authorization and UserInfo endpoints, is appended to an audit topic in the company's TessariDB database. The store itself refuses to rewrite or delete from it, and it is kept for 400 days.
What a message records:
- what was issued: client, user, subject, scopes, audience, the access token's
jti, the authentication method and the bound key; - what was refused and why;
- a replayed code, a reused refresh token, a revocation;
- sessions ended, grants withdrawn, accounts disabled;
- every console change as
admin_action, with the operator, the role, the change and the reason, and every refusal for a missing role; - every run of the emergency operator path.
A message never carries a token, code, verifier, assertion or proof. An issuance
that cannot be recorded is not answered and is logged as audit_unrecorded; a
refusal is answered either way.
Reading it
GET <ADMIN_URL>/admin/<company>/api/audit?after=<position>&limit= (role audit)
reads the trail in order, at most 100 messages a page, next naming the position
to read after. Each message carries its position, at, kind and only the
fields it was written with. The console's Audit trail section pages through it the
same way.