Аутентификация

Гибридная модель: JWT (UI / пользователи) + API-ключи (агенты / интеграции) + опциональный SSO/OIDC.

Вход (JWT)

bash curl -X POST http://localhost:8000/api/v1/auth/login \ -H "Content-Type: application/json" \ -d '{"email":"admin@example.com","password":"your-password"}'

Ответ содержит access_token и профиль пользователя (включая tenant_id).

Регистрация (self-serve)

Публичная регистрация создаёт tenant на тарифе Free и пользователя с ролью admin организации (никогда super_admin), затем возвращает тот же JWT, что и login.

bash curl -X POST http://localhost:8000/api/v1/auth/register \ -H "Content-Type: application/json" \ -d '{"email":"buyer@acme.com","password":"choose-a-strong-password","name":"Alex Buyer","organization":"Acme"}'

UI: /register.html. После регистрации пользователь уже вошёл и попадает на Тарифы, чтобы оплатить Pro / Business.

Отключение: REGISTRATION_ENABLED=false. Потребительские почты (Gmail, Mail.ru, Yandex, …) не становятся SSO-доменами allowed_email_domains; корпоративный домен привязывается, только если он ещё свободен.

API-ключи

Пользовательские / SDK-ключи (abi_)

```bash export JWT=""

curl -X POST http://localhost:8000/api/v1/auth/api-keys \ -H "Authorization: Bearer $JWT" \ -H "Content-Type: application/json" \ -d '{"name":"Production","notes":"Agent SDK"}' ```

raw_key (abi_...) возвращается один раз. Заголовок: X-API-Key: abi_...

Ключи tenant (bt_)

Создаются через POST /api/v1/tenants (JWT super_admin или X-Admin-Key). Используются для ingest, ограниченного данным business tenant.

SSO / OIDC

Поддерживаемые провайдеры (включаются через env-флаги): Google, Keycloak, Okta, Microsoft Entra ID.

1. Установите SSO_PUBLIC_BASE_URL / SSO_FRONTEND_URL на публичный HTTPS-ориджин.
2. Включите провайдера, например GOOGLE_SSO_ENABLED=true + client id/secret.
3. Redirect URI IdP: {SSO_PUBLIC_BASE_URL}/api/v1/auth/sso/callback
4. Настройте email-домены для tenant (allowed_email_domains) до входа пользователей — через Users → Organizations (super_admin) или PATCH /tenants/{id}. Домены уникальны между tenant.

Поток: /auth/sso/login → IdP → /auth/sso/callback (ID token с проверкой JWKS + nonce) → frontend /login.html?sso_code= → /auth/sso/exchange → JWT.

Неизвестные email-домены отклоняются (без тихого присоединения к Default Business).

Роли, назначаемые через SSO, ограничены уровнем admin — claims IdP никогда не выдают super_admin (платформенная роль остаётся только локальной).

Роли (RBAC)

Роль	Описание
super_admin	Платформа — все tenant (для аналитики требуется X-Tenant-Id)
admin	Администратор tenant — пользователи, агенты, billing
executive	CEO/CFO — дашборды и отчёты
manager	Операционное управление + API-ключи
viewer	Только чтение

Изоляция multi-tenant

Все агенты, события, метрики, ROI и отчёты ограничены tenant_id. JWT/abi_ наследуют tenant пользователя; ключи bt_ привязаны к tenant, которому принадлежит ключ.

Email-домены и vanity host

Поле	Значение
allowed_email_domains	SSO: какие email-домены присоединяются к этому tenant (уникальны глобально)
custom_domain	Опциональное vanity-имя хоста приложения (Settings → Domain; не маршрутизируется автоматически)

При SSO_SYNC_ROLES=true SSO может повышать роли из claims IdP, но не понижает роль, назначенную администратором, и никогда не назначает super_admin.