Authentication

AeThex services use different credentials for people, browser sessions, tenants, integrations, and operators. They must not be mixed.

Browser identity

KAEL currently supports:

• An AeThex identity-provider redirect flow beginning at GET /auth/login.
• A secure KAEL session cookie.
• Email one-time-code requests through POST /auth/email.
• Email code verification through POST /auth/verify.
• Session inspection through GET /auth/me.
• Logout through GET /auth/logout.

The session cookie is intended to be HttpOnly and Secure; browser JavaScript should not read it.

Passport context

After authentication, the runtime can resolve Passport profile and ARM membership information. That context contributes to server-calculated clearance.

The client must not grant itself a higher clearance level.

Tenant authentication

Approved server-side tenant integrations can supply x-tenant-key to tenant-aware endpoints.

Tenant keys can select:

• Tenant prompt.
• Tenant knowledge.
• Model policy.
• Tenant rate limits.

Never embed a tenant key in public browser JavaScript.

Operator authentication

Operator tokens authorize privileged KAEL operations. They are not user sessions and must remain in trusted server or operator environments.

Owner-level credentials can authorize particularly sensitive operations. They must be rotated if exposed and must never appear in documentation.

Webhook authentication

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.

See Webhooks.

Client checklist

• Verify the hostname before signing in.
• Use HTTPS.
• Keep cookies out of logs.
• Keep tenant and operator credentials server-side.
• Validate redirect targets.
• Rate-limit email code and verification attempts.
• Clear sessions on logout.
• Handle 401 and 403 differently.

Related documentation

• Passport
• Permissions
• Security
• KAEL Safety
• API Reference