Identity assertion
POST /v1/auth/assertion — a 17-second, single-use assertion bound to the session, used by the consent UI.
The identity assertion is how the consent UI tells the oauth context "this request really comes from this session". It is a signed JWE, not a token: it grants no access on its own, it only carries a proven identity across to another endpoint.
Request
POST /v1/auth/assertion, session token, no body.
{ "success": true, "assertion": "eyJ...", "expires_in": 17 }Properties
| Property | Value | Why |
|---|---|---|
| Lifetime | 17 seconds | Enough for the consent page to hand it over, far too short to be useful if leaked |
| Single use | Consumed on first verification | A replayed assertion would mean a second authorization for one consent click |
| Session-bound | Contains the session id and subject | The oauth side can tell which session and account the assertion belongs to |
| Encrypted | JWE | The payload is not readable by the browser or any intermediary |
Why not just pass the session token
The session token is audience auth. Handing it to the oauth context would either require relaxing the audience check — which removes the boundary between contexts — or be rejected.
The assertion is a narrowly scoped carrier: it proves identity to exactly the endpoints that accept it, and expires before it can be reused elsewhere.
Rules
| Rule | Notes |
|---|---|
| Issued per action | Request a fresh one for each consent submission; do not cache |
| Consumed by the receiver | preauthorize and authorize each consume it; one assertion cannot serve both |
No max_age requirement | The session is already authenticated; the assertion records the identity, not a fresh verification |
Related
- Where it is consumed: Authorization
- How the consent flow works: Authorization code flow