Идентификация и доступ

Зачем нужно

Identity отвечает за вход пользователя, аккаунты, профили, educator_profile, роли, семейный и организационный доступ, OAuth/OIDC, безопасность и аудит входа.

Документация домена должна быть достаточной, чтобы по ней можно было разработать identity-сервис с нуля: спроектировать БД, API, серверную часть, фронтенд, админку, интеграции и проверки безопасности.

Что входит

пользователи, профили, контакты и кастомные поля;
educator_profile как анкету/контакты/предметы/классы/trust profile преподавателя без выдачи прав;
аутентификация, сессии, JWT, refresh token rotation, saved accounts;
OAuth/OIDC authorization server для сервисов экосистемы;
RBAC, permissions, роли и назначения ролей;
семьи, детские аккаунты, родительский доступ, делегированные сессии;
справочник организаций, рабочий контур организаций и организационный access layer;
членство пользователей в организациях, роли и права внутри организаций;
команды внутри организаций и членство в командах;
приглашения, заявки на вступление, заявки на владение и передача владения;
ученики организации как не-user записи для организационных сценариев;
дубли, ручная склейка организаций и административное управление организациями;
безопасность пользователя: методы входа, активность, смена пароля, устройства;
audit logs и событийная семантика identity;
админка identity и bootstrap-хостинг части platform-owned runtime endpoints без переноса ownership.

Что не входит

общая UI-система, API-конвенции, событийная шина и observability — это platform/;
учебный прогресс, enrollment, курсы, уроки и дорожная карта — это lms;
Learning Workspace, learning_group и learning_group_participant — это lms;
биллинг, покупки, commercial account, договоры, счета, оплаты, entitlement и расчёт зарплат — это crm;
олимпиадное участие ученика, регистрация, работа, результат и публикация — это competitions;
подборки задач, ownership задач и попытки решения — это task-bank;
публичная витрина и SEO — это storefront;
управленческая аналитика и планирование — это management;
франшизные бизнес-процессы не выделены в текущие 7 доменов; если появится franchise-домен, он будет потреблять organization context из identity;
runtime capabilities platform-слоя: notifications, plugins, settings, navigation, i18n и feature flags — это platform по ADR-035. identity-api может временно хостить их endpoints, но не становится владельцем.

Чем владеет

Identity — источник истины по сущностям, перечисленным в ../../ecosystem/ownership.md#identity. В частности: user, user_profile, educator_profile, student_profile, user_credentials, user_auth_methods, user_sessions, refresh_token, user_role_assignment, family_group, user_family_group, delegated_session, child_device_authorization, organization_reference, organization, organization_membership, organization_team, organization_student, organization_ownership_claim, organization_ownership_transfer, organization_merge, permission_grant, oauth_client, oauth_authorization_code, oauth_refresh_token, actor_context.

Главные правила

Один пользователь — один аккаунт; роли, семьи, организации и контексты действия не подменяют личность.
Глобальной роли teacher нет.
educator_profile — анкета и trust profile, а не источник прав.
Learning Workspace не принадлежит identity; identity отдаёт ему user, educator_profile, family/organization scopes и actor context.
Пароль обязателен у каждого пользователя, даже если включён OTP/OAuth.
Access token короткоживущий, refresh token ротируется и хранится защищённо.
RBAC проверяется на сервере; фронтенд может скрывать элементы, но не отвечает за безопасность.
Семья и организация — разные модели доступа.
organization_reference помогает искать и нормализовать организации, но не даёт прав.
organization — identity-owned access/context layer; продуктовые домены используют его как контекст, но не владеют им.
organization_student — официальная или подтверждённая запись ученика внутри организации; это не student_profile семьи, не learning_group_participant, не competition_participant и не lms_enrollment.
Product permissions остаются в доменах-владельцах; identity хранит organization context, локальные роли и grants только с ключами из общего permissions catalog.
Actor context фиксирует действие в контексте ребёнка/организации без подмены userId.
Audit фиксирует действия безопасности и изменения прав.
Внешние интеграции работают через OAuth/OIDC, scoped API и события.

Карта документов

Канонический набор

Документ	Что описывает
scope.md	Акторы, зоны ответственности, соседи, контексты действия
data-model.md	Канонические сущности, связи, lifecycle
database-schema.md	PostgreSQL DDL, типы, FK, индексы, constraints
state-machines.md	Статусы и переходы auth, sessions, invitations, OAuth
api-map.md	Группы endpoints, права, ошибки, пагинация, идемпотентность
api-contracts.md	DTO, validation, response schemas, error codes
permissions-matrix.md	Endpoint/action → permission → scope → actor context → audit
events.md	Каталог событий и подписки
screen-spec.md	User/admin screens, поля, состояния, фильтры
user-flows.md	Внутридоменные сценарии identity
security.md	Сессии, методы входа, устройства, смена пароля
integrations.md	Связи identity с экосистемой и внешними провайдерами
test-plan.md	Unit, integration, e2e, security tests
acceptance.md	Критерии готовности домена

Подспеки

Документ	Что описывает
features/auth.md	Ядро аутентификации, JWT, sessions, brute-force защита
features/oauth-server.md	OIDC discovery, authorization code + PKCE, consent, tokens
features/users.md	Сущность пользователя, контакты, кастомные поля
features/family.md	Семейные группы, детские аккаунты, делегированные сессии
features/organizations.md	Организации, команды, членство, приглашения
features/rbac.md	Роли, permissions, назначения, проверки
features/notifications.md	Bootstrap-hosting spec для platform-owned notifications
features/admin.md	Админка identity
features/security-parameters.md	Password policy, JWT/OAuth TTL, retention, CORS, cookies

Платформенный слой (общие технические контракты)

Файлы UI Kit, API Gateway, Frontend Core, Topology, Plugins, Transports, Logging — общие платформенные документы и описаны в ../../platform/. Identity использует platform-слой, не дублирует его.

Порядок разработки с нуля

Прочитать ../../platform/overview.md и связанные платформенные документы.
Зафиксировать модель данных из data-model.md и DDL из database-schema.md.
Реализовать миграции, seed roles/permissions/settings и database constraints.
Реализовать state machines из state-machines.md.
Реализовать API guard, envelope/errors, audit по api-map.md и api-contracts.md.
Применить security.md и features/security-parameters.md.
Реализовать users, auth, sessions, refresh token rotation и reset password (features/auth.md).
Реализовать RBAC (features/rbac.md), family (features/family.md) и organizations (features/organizations.md).
Добавить OAuth/OIDC authorization server (features/oauth-server.md).
Подключить события identity (events.md); platform-owned notifications подключаются как bootstrap capability по features/notifications.md.
Собрать identity-admin-web и пользовательские экраны по screen-spec.md.
Прогнать test-plan.md и проверить домен по acceptance.md.

Зачем нужно​

Что входит​

Что не входит​

Чем владеет​

Главные правила​

Карта документов​

Канонический набор​

Подспеки​

Платформенный слой (общие технические контракты)​

Порядок разработки с нуля​

Связанные документы​