Эссе о разработке игр, мышлении и книгах

Стрёмная архитектура аутентификации Ory ru en

Tiendil пытается понять как работает Ory (c) ChatGPT & Hieronymus Bosch.

Tiendil пытается понять как работает Ory (c) ChatGPT & Hieronymus Bosch.

Пожалуюсь вам, так как либо сюда писать, либо в спортлото.

Я тут погружаюсь в тему аутентификации чуть глубже, чем мне хотелось бы, и столкнулся с тем, что сейчас чуть ли не best-practice это со своего auth проксика делать запросы в сторонние сервисы, чтобы наполнить запрос дополнительной инфой для бэкенда.

Например, если есть API, которое доступно одновременно для аутентифицированных и анонимных пользователей, то Ory Oathkeeper (auth proxy) не может добавить заголовок с id пользователя: либо надо закрыть api от анонимных пользователей либо не добавлять заголовок.

Решать советуют через создание своего микросервиса (!): проксик обращется к микросервису (на каждый запрос!) микросервис обращается к Ory Kratos (!) — это хранилка сессий (среди прочего), получает сессию и возвращает инфу для проксика. Т.е. чтобы добавить 1 заголовок, надо делать цепочку из двух запросов по инфре на каждый запрос к api. (или из трёх, в теории Kratos может в базу или кэш сходить).

Это нонсенс какой-то.

Причём Ory — это топовое решение, его OpenAI всякие используют.

Чтобы развернуть auth* решение на Ory надо (упрощённо):

  • поднять Ory Kratos — управление сессиями и логином/регистрацией;
  • поднять Ory Hydra — отвечает за OAuth2, OIDC, etc.;
  • поднять Ory OAthkeeper — собственно проксик;
  • реализовать собственное GUI, которое взаимодействует Kratos;
  • реализовать собственный бэкенд сервис (и иногда GUI к нему), который нужен для Hydra;
  • и вот в моём случае допилить ещё микросервис для установки одного заголовка. ОДНОГО ЗАГОЛОВКА!

Это чтобы иметь регистрацию, логин и какой-то унифицированный доступ с возможностью их глубоко тюнить для всяких B2B.

И тут ещё нет всяких специфичных штук вроде отслеживания rate limit / quotas, reverse proxy, управления HTTPS серитфикатами и прочего.

Причём альтернативные решения используют в основном только два компонента: "Identity Provider" + Auth proxy. Между ними по-разному может распределяться пограничная логика, но сущности не плодятся.

По крайней мере я собрал для себя работающую инфру с Keycloak + Apache APISIX и она работает. Но решил, к своему ужасу, посмотреть как серьёзные люди делают. Как это всё развидеть теперь.

IdP + Auth proxy, если разобраться — отличная и удобная концепция — никогда нельзя пилить велосипеды для безопасности, эта пара как раз решает проблему. Но это 2 сущности, не 5! Вы пробовали когда-нибудь конфигурировать, отлаживать и долгосрочно поддерживать 5 сильносвязанных сервисов с нетривиальной логикой? Не пробуйте :-)

Человечество куда-то не туда свернуло.

P.S. Есть, конечно, вероятность, что я недосмотрел чего-то в документации Ory по поводу сервиса для установки заголовка — но это, по-сути, самая маленькая проблема, которую надо решать в этом случае :-)