Blame
|
1 | # Authentication |
||||||
| 2 | ||||||||
|
3 | AeThex services use different credentials for people, browser sessions, tenants, integrations, and operators. They must not be mixed. |
||||||
|
4 | |||||||
|
5 | | Field | Value | |
||||||
| 6 | |---|---| |
|||||||
| 7 | | Documentation status | Active | |
|||||||
| 8 | | Applies to | Passport, KAEL, API clients, tenants, and integrations | |
|||||||
| 9 | | Last source review | 2026-06-26 | |
|||||||
|
10 | |||||||
|
11 | ## Browser identity |
||||||
|
12 | |||||||
|
13 | KAEL currently supports: |
||||||
|
14 | |||||||
|
15 | - An AeThex identity-provider redirect flow beginning at `GET /auth/login`. |
||||||
| 16 | - A secure KAEL session cookie. |
|||||||
| 17 | - Email one-time-code requests through `POST /auth/email`. |
|||||||
| 18 | - Email code verification through `POST /auth/verify`. |
|||||||
| 19 | - Session inspection through `GET /auth/me`. |
|||||||
| 20 | - Logout through `GET /auth/logout`. |
|||||||
|
21 | |||||||
|
22 | The session cookie is intended to be `HttpOnly` and `Secure`; browser JavaScript should not read it. |
||||||
|
23 | |||||||
|
24 | ## Passport context |
||||||
|
25 | |||||||
|
26 | After authentication, the runtime can resolve Passport profile and ARM membership information. That context contributes to server-calculated clearance. |
||||||
|
27 | |||||||
|
28 | The client must not grant itself a higher clearance level. |
||||||
| 29 | ||||||||
| 30 | ## Tenant authentication |
|||||||
| 31 | ||||||||
| 32 | Approved server-side tenant integrations can supply `x-tenant-key` to tenant-aware endpoints. |
|||||||
| 33 | ||||||||
| 34 | Tenant keys can select: |
|||||||
| 35 | ||||||||
| 36 | - Tenant prompt. |
|||||||
| 37 | - Tenant knowledge. |
|||||||
| 38 | - Model policy. |
|||||||
| 39 | - Tenant rate limits. |
|||||||
| 40 | ||||||||
| 41 | Never embed a tenant key in public browser JavaScript. |
|||||||
| 42 | ||||||||
| 43 | ## Operator authentication |
|||||||
| 44 | ||||||||
| 45 | Operator tokens authorize privileged KAEL operations. They are not user sessions and must remain in trusted server or operator environments. |
|||||||
| 46 | ||||||||
| 47 | Owner-level credentials can authorize particularly sensitive operations. They must be rotated if exposed and must never appear in documentation. |
|||||||
| 48 | ||||||||
| 49 | ## Webhook authentication |
|||||||
| 50 | ||||||||
| 51 | AeThex deployment webhooks require an HMAC signature in the configured Gitea or GitHub signature header. Discord interactions use Discord’s Ed25519 signature and timestamp headers. |
|||||||
| 52 | ||||||||
| 53 | See [[Webhooks]]. |
|||||||
| 54 | ||||||||
| 55 | ## Client checklist |
|||||||
| 56 | ||||||||
| 57 | - Verify the hostname before signing in. |
|||||||
| 58 | - Use HTTPS. |
|||||||
| 59 | - Keep cookies out of logs. |
|||||||
| 60 | - Keep tenant and operator credentials server-side. |
|||||||
| 61 | - Validate redirect targets. |
|||||||
| 62 | - Rate-limit email code and verification attempts. |
|||||||
| 63 | - Clear sessions on logout. |
|||||||
| 64 | - Handle `401` and `403` differently. |
|||||||
| 65 | ||||||||
| 66 | ## Related documentation |
|||||||
| 67 | ||||||||
| 68 | - [[Passport]] |
|||||||
| 69 | - [[Permissions]] |
|||||||
| 70 | - [[Security]] |
|||||||
| 71 | - [[KAEL Safety]] |
|||||||
| 72 | - [[API Reference]] |
|||||||