ARCANADA
СБОРКА L2 · цель L4

Auth Arcana

Единый провайдер идентичности для всей экосистемы.

Когда у каждого сервиса свои пользователи, пароли и сессии, идентичность превращается в копии, которые расходятся. Auth Arcana — единый провайдер идентичности для всей экосистемы: все сервисы Arcanada делегируют идентичность ему, и ни у одного нет собственной таблицы пользователей.

Это сервер OIDC/OAuth 2.1 с Passkeys, федерацией для 10+ провайдеров (Google, GitHub, Telegram, VK, Yandex, Mail.ru, OK.ru, Apple, Microsoft, Discord), авторизацией ReBAC через OpenFGA, персональными токенами и API-ключами, журналом аудита и управлением учётными данными через Vault.

Статус
Работает, активно развивается
Автономность (AAL)
L2 → L4
Протоколы
OIDC / OAuth 2.1, OpenFGA
Федерация
10+ провайдеров

01

Одна идентичность без копий

Сервисы спрашивают у Auth Arcana, кто пользователь, и не хранят пользователей сами.

02

Современный вход

Passkeys (WebAuthn) и федерация для 10+ провайдеров на OIDC / OAuth 2.1 с PKCE.

03

Доступ по связям

Авторизация ReBAC через OpenFGA, персональные токены и сервисные аккаунты с учётными данными из Vault.

Чему научило слабое звено

Живой OIDC-провайдер с двумя издателями (.ai/.one) проверяет зависимость от Vault в /health и валидирует секреты при старте. Остаётся пробел — нет аварийного выключателя: устаревший AppRole secret-id однажды около 36 часов работал в деградации без автоматического алерта (INFRA-0288).

Возможности

Уже работает

  • OIDC / OAuth 2.1 с PKCE

Статус не указан

  • Passkeys (WebAuthn) и федерация (10+ провайдеров)
  • Авторизация ReBAC через OpenFGA
  • Персональные токены доступа (arc_pat_*)
  • Сервисные аккаунты с выдачей учётных данных через Vault

Текущий уровень автономии

L2
Что значат уровни →

Слабое звено

Живой dual-issuer OIDC-провайдер (.ai/.one) с /health, проверяющим зависимость от Vault (секреты валидируются при старте). Потолок — отсутствие dead-man's switch: устаревший AppRole secret-id однажды ~36ч работал в деградации без автоматического алерта (INFRA-0288).

Roadmap до L4

  1. L2 — /health endpoint, классифицированные ошибки, отчёт о деплое в Ops Bot.
  2. L3 — структурированные pino-логи в Loki, сигнал живости, приёмочная проверка после деплоя, проверка учётных данных при старте.
  3. L4 — предохранитель для Vault, резервный PostgreSQL (HA), журнал восстановления, жёсткий лимит запросов на всех эндпойнтах.

Следующий шаг

Оцените текущую сборку и план развития

Статус СБОРКА означает активную разработку, а не обещание публичной доступности. Ориентируйтесь на текущие возможности и roadmap выше.

Посмотреть путь к целевому уровню