...
A process would clean these out after the configured drift (10 minutes)
| Column | Type | Description |
|---|---|---|
| idjwt_jti | varchar | e.g. uuid of this entry (sent from client) |
| millisjwt_since_1970iat | integer | millis seconds since 1970 that this was usedissued |
Manage passwords
UI for admins to set a user's (or local entity's) UI password or could restrict source IP cidrs. UI passwords would need to follow strength rules
...
- To authenticate with JWT the client would
- Generate a valid jwt jti (e.g. uuid)
- Have the correct time within configured drift (10 minutes?), get the millis seconds since 1970 (GMT)
Send a "Bearer" authorization header sfdlh23kjh.kjhsdfkjhsf.kjh345kjhkjh (three parts separated by dot)
First part is the header is base64 url encoded
Code Block { alg: "RS-256", typ: "JWT" }The second part is what makes the token unique and identifies the user
- uuid jti is a unique uuid value per request (across clusters), cannot be re-used. e.g. a uuid
- username is: system name of local entity
- millisSince1970iat: Number of millis seconds since 1970 (that the ticket is issued), the timestamp number received on server needs to be within the allowable time drift
Code Block { uuidjti: "abc123", username: "org:businessSchool:credentials:wiki", millisSince1970iat: 1234567 }
- Thus the same request cannot be replayed