➡️ Делимся записью вебинара "Модульность без фанатизма: о чем на самом деле книга Balancing Coupling"

Ведущий: Сергей Баранов.

Гостем был Влад Хононов, архитектор и автор книг «Learning Domain-Driven Design» и «Balancing Coupling in Software Design». Вебинар посвящён идеям из второй книги.

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

Смотрите видео:

👮‍♂️ ВК
🌐 Рутуб
📺 YouTube

Доклад "Строим единую платформу аутентификации на основе Keycloak" с Saint HighLoad++ 2025 от Виктора Попова

Пост, который хотел написать еще летом, но ведь лучше поздно, чем никогда...
В одном из предыдущих постов про книгу “Cloud Native Data Security with OAuth" я написал, что глава 11 Managing a Cloud Native Authorization Server в ней получилась не самой полезной. Так вот, для улучшения эффекта можно посмотреть доклад с летнего Highload от @ivanovivanivanovich1.

В докладе это явно не проговаривается, но речь будет идти об аутентификации именно внутренних пользователей.

Говорит автор о том, что понимает под платформой и какие ключевые особенности ей характерны:
1️⃣ One size fits most - платформа подходит под большинство ваших задач
2️⃣ Golden path - платформа дает "дорогу из золотого кирпича", по которой должно быть легко и удобно идти
3️⃣ Compliance - пользуясь платформой, вы удовлетворяете требованиям: техническим, информационной безопасности и др.

Рассматриваются следующие варианты реализации платформы аутентификации:
🔵Пишем свое решение
🔵SaaS (Auth0, Okta, etc)
🔵"Экзотический" on-prem: Ory Hydra, ZITADEL, Casdoor
🔵Keycloak

К какому выбору дальше приходит автор, думаю, пояснять не надо :)

Кстати, Виктор отмечает, что уже полтора года ищет, кто может на митапе рассказать про свой опыт использования Ory Hydra, отмечая малую популярность решения. Я тут частично соглашусь: хоть и есть несколько компаний в РФ, кто использует у себя стек от Ory, ни выступить, ни написать про это почему-то никто не хочет. А жаль.

Далее автор делится своими принципами в использовании Keycloak:

1️⃣ Keycloak использовать только для аутентификации
Кстати, ругает здесь подходы, когда возможность "входа" в то или иное приложение задается на стороне IdP, говоря, что это плохой UX. Интересно, что я сам долгое время был сторонником схожей школы мысли. Однако не так давно переубедил себя: отдельные приложения могут не поддерживать или не хотеть поддерживать гибкие политики аутентификации, и настраивать возможность и правила для входа в приложения можно и в одном месте - на стороне IdP. Так что здесь все не так однозначно.
2️⃣ Пользователи хранятся в AD-каталоге, а не в Keycloak. AD - источник правды
3️⃣ Не используют регистрацию пользователей в Keycloak
4️⃣ Не используют SAML
Здесь также говорится о том, что SAML - "небезопасный протокол", с чем не могу согласиться, это не так.
5️⃣ Конфигурация управляется 100% as a code

Рассказывает о том, как для себя подошли к решению задачи high availability (HA): размещают поды с KK в 3 AZ, при этом для базы используют растянутый кластер Patroni + PostgreSQL, где мастер находится только в одной из AZ. Но отмечает применимость такого подхода только при близкорасположенных ДЦ, чтобы не было больших задержек при репликации. Ну и логично, что воспринимается такая инсталляция как локальная, а не гео-распределенная. То есть фокус, полагаю, на отказоустойчивости внутри одного региона.

Деплоят в K8s, для реализации IaC используют Pulumi, чего докладчик и всем советует.

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

#video #iam_general

Про термины authorization request/response и token request/response

Вы, вероятно, уже встречали упоминание подобных терминов в контексте OAuth/OIDC, по крайней мере автор данного канала активно их использует. Здесь как раз разберемся, зачем они нужны и что подразумевают.

Начнем с того, что RFC 6749 вводит понятия Authorization Endpoint и Token Endpoint.

Authorization endpoint - used by the client to obtain authorization from the resource owner via user-agent redirection.

Обычно выглядит как что-то вроде .../auth или .../authorize.

Token endpoint - used by the client to exchange an authorization grant for an access token, typically with client authentication.

На самом деле, возвращаться может не только access token, но об этом далее. Представляет собой нечто вроде .../token.

Соответственно, запросы к этим эндпоинтам и называют Authorization Request и Token Request.

Authorization Request - это HTTP-запрос к Authorization Endpoint, являющийся первым шагом в основных grant flows. То есть это запрос, с помощью которого resource owner предоставляет авторизацию (разрешение) OAuth client для доступа к ресурсам от его лица.

Token Request - это HTTP-запрос к Token Endpoint, который служит для получения токенов, таких как access token, refresh token, ID token.

А ответы на данные запросы в соответствие так и называются: Authorization Response и Token Response.

И все было хорошо, пока народ огня не развязал войну ребята из OpenID Foundation не написали спецификацию OIDC. Где ввели ещё и понятие Authentication Request... Вот формальное определение оттуда:

Authentication Request - OAuth 2.0 Authorization Request using extension parameters and scopes defined by OpenID Connect to request that the End-User be authenticated by the Authorization Server, which is an OpenID Connect Provider, to the Client, which is an OpenID Connect Relying Party.

Стало понятнее, да ведь? То есть предлагается выделить Authorization Request обладающий рядом параметров, в отдельный термин. Увы, это только внесло большую путаницу. Вы можете сами поискать по тексту спецификации эти два понятия и попробовать понять, почему в каждом месте использовано именно такое.
Поэтому я лично вообще стараюсь отдельно этот термин не использовать и ограничиваюсь везде понятием Authorization request.

С понятийной частью, вроде, разобрались, осталось выяснить, зачем вообще уделять такое внимание этим определениям. Может, это буквоедство и лишнее усложнение?

На самом деле, смысл в их использовании есть. Когда мы описываем какое-либо поведение, нам часто так или иначе нужно упоминать эти запросы и ответы на них. Внутри команд, работающих с аутентификацией, часто можно встретить подход, где оперируют названиями конкретных эндпоинтов. Правда это не всегда может быть удобно в устной речи.

Куда более интересно становится, когда мы хотим описать некоторую общую логику, не привязываясь при этом к использованию конкретного IAM-решения. И желательно, чтобы нас поняли люди, работающие хоть с Keycloak, хоть с ZITADEL, хоть с самописными реализациями. И у всех этих конкретных решений названия данных эндпоинтов могут отличаться.

Таким образом, используя подобные универсальные термины, мы можем говорить без привязки к конкретной технологии, но при этом оставляя возможность быть понятыми верно и однозначно.

Так что пост написан с целью пропаганды использования таких терминов, что, надеюсь, поможет всем нам лучше понимать друг друга и проще вести дискуссии на профессиональные темы ⛔️

#oauth