Skip to content

Миграция с ORY Hydra ​

Granto переносит модель login/consent Hydra, а не копирует её байт-в-байт. Цель — снять Hydra, не переписывая существующий login/consent app с нуля.

Что совпадает ​

  • Пути и ментальная модель Admin API — как у Hydra: login_challenge / consent_challenge, accept / reject.
  • Default-режим: challenge id + доступ к Admin API — этого достаточно, как у Hydra, для бесшовного переноса существующих login-приложений.
  • Strict-режим: можно включить обязательный accept_token на каждый Accept — усиление без изменений в публичном RFC-периметре.

Что отличается — честно ​

Мы не обещаем bit-identical API. Конкретно:

  • Challenge — короткий UUID в Redis, а не encrypted blob, как у Hydra. Это проще отлаживать и аудировать, но формат другой — если ваш login app парсит challenge как непрозрачный токен (как и положено по спеке), разницы он не заметит.
  • Нет собственного SIEM/аналитического audit-store — вместо этого audit-поток (outbox → stdout/webhook), подробнее — статус.
  • consent как отдельный устанавливаемый модуль с engine + plugins — у Hydra login/consent app пишется с нуля, своим кодом, на свой страх и риск.

Что переносить не нужно ​

Если ваш login/consent app сегодня говорит с Hydra Admin API по challenge/accept/reject — менять его логику не придётся, только endpoint. Детали путей и payload — в reference-документации Admin API (roadmap для этого сайта; пока — core/api/admin/ в репозитории).

AGPLv3