OAuch и работы от его авторов
OAuch - это open-source инструмент, проверяющий соблюдение лучших практик в области безопасности для OAuth 2.0/OIDC-совместимых IdP (читай - authorization server), тем самым подсвечивая актуальные угрозы. Он должен проверять совместимость IdP с самим OAuth-фреймворком, а также насколько IdP реализует указанные разной степени обязательности практики и из ряда других документов.
У авторов есть несколько опубликованных исследований, решил их изучить.
Первая по хронологии статья - это “OAuch: Exploring Security Compliance in the OAuth 2.0 Ecosystem”, опубликована она была еще осенью 2022 года, а учитывая, что авторы предоставляли срок в 1 год для исправления уязвимостей, само исследование было проведено как минимум годом ранее.
Это первая работа от авторов, в которой они выполняют исследование публичных IdP, а также описывают сам инструмент и принципы, на которых основана его работа. Авторы поставили довольно амбициозную цель - улучшение OAuth-ландшафта за счет проведения аудита публичных IdP на предмет соответствия рекомендациям OAuth в части информационной безопасности с дальнейшим предоставлением результатов разработчикам IdP.
Авторы взяли для исследования 100 публично доступных IdP, выделив 75 из первых 10 000, а оставшиеся 25 - из первого 1 000 000 списка доступных API в ProgrammableWeb (проект в 23 году закрылся).
Модель угроз основана на RFC 6819, но с некоторым расширением. OAuch предполагает наличие тест-кейсов в соответствие рекомендациям, так в исследовании участвовало 113 тестов. Кстати, авторы отмечают, что документы-спецификации описаны достаточно точно и четко, поэтому создание тест-кейсов на их основе не было очень сложным.
Подчеркивается, что OAuch проверяет только сами IdP, и не учитывает угрозы для RP, а также некоторые уязвимости, которые могут быть актуальны, но не относятся к OAuth.
Интересны результаты, показывающие использование различных authorization grants. Так, например, 94% IdP поддерживали authorization code grant и только 1% - device code grant (хотя авторы отмечают, что 1% в данном случае - не совсем точное значение).
Вообще анализ показал, что 97/100 IdP имели хотя бы одну незакрытую угрозу (однако от себя тут добавлю, что некоторые кейсы выглядят несколько специфично). И соответственно ни один IdP не прошел полную проверку в понимании авторов.
Пишут, что в среднем IdP не реализовывали 20% от обязательных рекомендаций из спецификаций и 33% от всех рекомендаций. Также отмечается, что рекомендации из Best Current Practices (BCP), а не из основного документа OAuth 2.0 имели почти в три раза (!) меньшую вероятность имплементации. Так что, возможно, что идея сведения всех спецификаций в один гигадокумент OAuth 2.1 и имеет свой смысл. Хотя, буду честен: текущий далеко не полный черновик уже имеет время прочтения более 2 часов. При всей моей вере в человечество, мне трудно представить, что от сведения всего в один документ сильно больше людей его внимательно станут изучать…
Очень интересно было узнать, что на момент проведения исследования только 21% IdP поддерживали PKCE. А строгое сравнение зарегистрированных URL для redirect URI выполняли только 53% IdP…
Также авторы отмечают очень интересную мысль, с которой я согласен:
Следовательно, IdP в таком случае имеет бОльшую ответственность в том числе в предъявлении строгих требований к RP, чтобы у тех было меньше шансов выстрелить себе в ногу.
В итоге авторы приходят к выводу, что… OAuth-экосистема находилась в довольно плачевном состоянии, и многие IdP не реализовывали критичные меры защиты. Также в ряде случаев разработчики были в курсе, что они не соблюдают защитные меры, однако по ряду причин (в статье они перечислены) тем не менее продолжали жить с этим.
Далее мы посмотрим на следующую статью авторов, где они провели повторный анализ два года спустя, чтобы узнать, что же изменилось за это время.
Кстати, если кто-то уже пробовал использовать OAuch на практике, напишите, интересно узнать реальные отзывы.
#security #oauth #paper
OAuch - это open-source инструмент, проверяющий соблюдение лучших практик в области безопасности для OAuth 2.0/OIDC-совместимых IdP (читай - authorization server), тем самым подсвечивая актуальные угрозы. Он должен проверять совместимость IdP с самим OAuth-фреймворком, а также насколько IdP реализует указанные разной степени обязательности практики и из ряда других документов.
У авторов есть несколько опубликованных исследований, решил их изучить.
Первая по хронологии статья - это “OAuch: Exploring Security Compliance in the OAuth 2.0 Ecosystem”, опубликована она была еще осенью 2022 года, а учитывая, что авторы предоставляли срок в 1 год для исправления уязвимостей, само исследование было проведено как минимум годом ранее.
Это первая работа от авторов, в которой они выполняют исследование публичных IdP, а также описывают сам инструмент и принципы, на которых основана его работа. Авторы поставили довольно амбициозную цель - улучшение OAuth-ландшафта за счет проведения аудита публичных IdP на предмет соответствия рекомендациям OAuth в части информационной безопасности с дальнейшим предоставлением результатов разработчикам IdP.
Авторы взяли для исследования 100 публично доступных IdP, выделив 75 из первых 10 000, а оставшиеся 25 - из первого 1 000 000 списка доступных API в ProgrammableWeb (проект в 23 году закрылся).
Модель угроз основана на RFC 6819, но с некоторым расширением. OAuch предполагает наличие тест-кейсов в соответствие рекомендациям, так в исследовании участвовало 113 тестов. Кстати, авторы отмечают, что документы-спецификации описаны достаточно точно и четко, поэтому создание тест-кейсов на их основе не было очень сложным.
Подчеркивается, что OAuch проверяет только сами IdP, и не учитывает угрозы для RP, а также некоторые уязвимости, которые могут быть актуальны, но не относятся к OAuth.
Интересны результаты, показывающие использование различных authorization grants. Так, например, 94% IdP поддерживали authorization code grant и только 1% - device code grant (хотя авторы отмечают, что 1% в данном случае - не совсем точное значение).
Вообще анализ показал, что 97/100 IdP имели хотя бы одну незакрытую угрозу (однако от себя тут добавлю, что некоторые кейсы выглядят несколько специфично). И соответственно ни один IdP не прошел полную проверку в понимании авторов.
Пишут, что в среднем IdP не реализовывали 20% от обязательных рекомендаций из спецификаций и 33% от всех рекомендаций. Также отмечается, что рекомендации из Best Current Practices (BCP), а не из основного документа OAuth 2.0 имели почти в три раза (!) меньшую вероятность имплементации. Так что, возможно, что идея сведения всех спецификаций в один гигадокумент OAuth 2.1 и имеет свой смысл. Хотя, буду честен: текущий далеко не полный черновик уже имеет время прочтения более 2 часов. При всей моей вере в человечество, мне трудно представить, что от сведения всего в один документ сильно больше людей его внимательно станут изучать…
Очень интересно было узнать, что на момент проведения исследования только 21% IdP поддерживали PKCE. А строгое сравнение зарегистрированных URL для redirect URI выполняли только 53% IdP…
Также авторы отмечают очень интересную мысль, с которой я согласен:
RP cannot be expected to make the best security decisions
Следовательно, IdP в таком случае имеет бОльшую ответственность в том числе в предъявлении строгих требований к RP, чтобы у тех было меньше шансов выстрелить себе в ногу.
В итоге авторы приходят к выводу, что… OAuth-экосистема находилась в довольно плачевном состоянии, и многие IdP не реализовывали критичные меры защиты. Также в ряде случаев разработчики были в курсе, что они не соблюдают защитные меры, однако по ряду причин (в статье они перечислены) тем не менее продолжали жить с этим.
Далее мы посмотрим на следующую статью авторов, где они провели повторный анализ два года спустя, чтобы узнать, что же изменилось за это время.
Кстати, если кто-то уже пробовал использовать OAuch на практике, напишите, интересно узнать реальные отзывы.
#security #oauth #paper
❤2🤔2
Статья "Revisiting OAuth 2.0 Compliance: A Two-Year Follow-Up Study"
Вторая статья от авторов OAuch, в которой они возвращаются к исследованным в рамках своей первой работы IdP.
Здесь авторы задаются целью выяснить, какие изменения произошли в соответствии IdP стандартам, и для этого сравнивают свои текущие измерения с прошлыми.
В прошлый раз авторы проверяли работу 100 публичных IdP, из них 92 были протестированы повторно в марте 2023 года. Восемь IdP авторы уже не смогли повторно проверить по ряду причин, поэтому для сравнения им пришлось слегка пересчитать результаты. Кстати, из этой статьи мы узнаем, что первичные измерения проводились еще в 2020 году (а не 2021, как можно было предположить из первой работы).
Авторы выделяют отдельно:
🔵 Распространение применения обязательного запроса согласия (consent) у пользователей для public clients (44.1% -> 58.8%)
🔵 Рост использования "access token rotation"(на 9.8 п.п., до 58.9%) - тут, увы, непонятно, что под этим понимается. Найти такого тест-кейса у них я не смог. В статье пишут размыто "frequently replacing tokens with newly minted tokens"
🔵 Повысилась поддержка PKCE на 7.3 п.п. и стала составлять уже 31.8%
Некоторое повышение failure rate для тестов по спецификации OIDC авторы объясняют тем, что один сайт начал поддерживать OIDC, однако имплементировал его с отличиями от спецификации.
В итоге авторы приходят не к самым интересным выводам:
🔵 Да, за два года IdP стали больше соответствовать стандартам и лучшим практикам
🔵 Но, несмотря на это, подчеркивается, что проблемы еще оставались
Статья, надо сказать, очень короткая: если отбросить вводную часть и заключение, "мяса" в этот раз остается совсем мало.
#security #oauth #paper
Вторая статья от авторов OAuch, в которой они возвращаются к исследованным в рамках своей первой работы IdP.
Здесь авторы задаются целью выяснить, какие изменения произошли в соответствии IdP стандартам, и для этого сравнивают свои текущие измерения с прошлыми.
В прошлый раз авторы проверяли работу 100 публичных IdP, из них 92 были протестированы повторно в марте 2023 года. Восемь IdP авторы уже не смогли повторно проверить по ряду причин, поэтому для сравнения им пришлось слегка пересчитать результаты. Кстати, из этой статьи мы узнаем, что первичные измерения проводились еще в 2020 году (а не 2021, как можно было предположить из первой работы).
Авторы выделяют отдельно:
Некоторое повышение failure rate для тестов по спецификации OIDC авторы объясняют тем, что один сайт начал поддерживать OIDC, однако имплементировал его с отличиями от спецификации.
В итоге авторы приходят не к самым интересным выводам:
Статья, надо сказать, очень короткая: если отбросить вводную часть и заключение, "мяса" в этот раз остается совсем мало.
#security #oauth #paper
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🤔1
Статья "Is Your OAuth Middleware Vulnerable? Evaluating Open-Source Identity Provider's Security"
Третья и последняя из опубликованных статей от авторов OAuch, которая вышла в конце 24 года. Публично она пока недоступна, однако по секретным каналам мне удалось раздобыть текст публикации.
Надо сказать, что название интригующее, поэтому ее хотел прочитать больше предыдущих. Однако само содержание, оказалось менее интересным, чем ожидал.
Итак, авторы решили вместо исследования публичных IdP, как ранее, проверить восемь Open-Source IAM-решений, которые выступают как OAuth authorization server:
🔵 Authentik
🔵 Boruta
🔵 Casdoor
🔵 Glewlwyd
🔵 Keykloak
🔵 Ory Hydra
🔵 Spring AS
🔵 Zitadel
Авторы отмечают, что не просто взяли "голые" решения, а сконфигурировали каждый IdP (в статье используют такую терминологию) в соответствии с актуальными best practices, насколько решения это позволяли. В частности:
- отключили ряд grant flow, таких как Implicit grant
- установили короткое время жизни токенов доступа
- включили и сделали обязательным использование PKCE
Тесты также проводили для двух случаев: для public и для confidential clients.
Найденные слабые места авторы категоризировали в следующем виде:
🔵 Insufficient redirect URI validation
1) Incorrect redirect URI matching (IRM)
2) Open redirectors (OR)
3) Insufficient redirect URI validation (IRV)
🔵 Multiple exchange of single-use tokens
4) Incomplete revocation after authorization code multi-exchange (IRC)
5) Incomplete revocation with refresh token rotation (IRR)
🔵 PKCE adoption challenges
6) PKCE not mandatory for public RPs or not supported for confidential RPs (PPC)
7) No RP authentication when PKCE is used (PCA)
8) PKCE downgrade attack (PD)
🔵 Refresh token mismanagement
9) No RP authentication check when a using refresh tokens (IRA)
10) Refresh token rotation not used for public RPs (RTR)
Логично отмечается, что все обнаруженные слабые места являются известными и контрмеры для них описаны в каких-либо OAuth-документах.
Пишут, что анализ показал, что большинство проблем были связаны с неоднократным использованием одноразовых токенов и PKCE: по 7 и 11 проблем в соответствующих категориях. В частности выделяют Incomplete revocation with refresh token rotation (IRR), PKCE not mandatory for public RPs or not supported for confidential RPs (PPC), и PKCE downgrade attack (PD). Отмечают, что более половины рассмотренных IdP были подвержены атаке PKCE downgrade. При этом интересно подчеркивают:
Сравнительный анализ между коммерческими и некоммерческими решениями при этом не выявил сильной разницы. Также в ходе раскрытия информации разработчикам были опубликованы две CVE: CVE-2024-23647 и CVE-2024-22258. А представители одного из продуктов вообще не ответили авторам, несмотря на попытки с ними связаться 😃
В заключение авторы указывают, что проблемы были обнаружены в семи из восьми рассмотренных имплементаций (отличились только ребята из Ory). Ну и говорят, что, казалось бы, существующие BCP предоставляют достаточные и описанные меры, но разработчики все еще не следуют этим рекомендациям. А также авторы говорят, что ждут OAuth 2.1 как новый комплексный baseline standard (я все еще несколько пессимистичен, правда, насчет таких взглядов).
#oauth #paper #security
Третья и последняя из опубликованных статей от авторов OAuch, которая вышла в конце 24 года. Публично она пока недоступна, однако по секретным каналам мне удалось раздобыть текст публикации.
Надо сказать, что название интригующее, поэтому ее хотел прочитать больше предыдущих. Однако само содержание, оказалось менее интересным, чем ожидал.
Итак, авторы решили вместо исследования публичных IdP, как ранее, проверить восемь Open-Source IAM-решений, которые выступают как OAuth authorization server:
Авторы отмечают, что не просто взяли "голые" решения, а сконфигурировали каждый IdP (в статье используют такую терминологию) в соответствии с актуальными best practices, насколько решения это позволяли. В частности:
- отключили ряд grant flow, таких как Implicit grant
- установили короткое время жизни токенов доступа
- включили и сделали обязательным использование PKCE
Тесты также проводили для двух случаев: для public и для confidential clients.
Найденные слабые места авторы категоризировали в следующем виде:
1) Incorrect redirect URI matching (IRM)
2) Open redirectors (OR)
3) Insufficient redirect URI validation (IRV)
4) Incomplete revocation after authorization code multi-exchange (IRC)
5) Incomplete revocation with refresh token rotation (IRR)
6) PKCE not mandatory for public RPs or not supported for confidential RPs (PPC)
7) No RP authentication when PKCE is used (PCA)
8) PKCE downgrade attack (PD)
9) No RP authentication check when a using refresh tokens (IRA)
10) Refresh token rotation not used for public RPs (RTR)
Логично отмечается, что все обнаруженные слабые места являются известными и контрмеры для них описаны в каких-либо OAuth-документах.
Пишут, что анализ показал, что большинство проблем были связаны с неоднократным использованием одноразовых токенов и PKCE: по 7 и 11 проблем в соответствующих категориях. В частности выделяют Incomplete revocation with refresh token rotation (IRR), PKCE not mandatory for public RPs or not supported for confidential RPs (PPC), и PKCE downgrade attack (PD). Отмечают, что более половины рассмотренных IdP были подвержены атаке PKCE downgrade. При этом интересно подчеркивают:
The BCP states that “Authorization servers MUST mitigate PKCE Downgrade Attacks by ensuring that a token request containing a code verifier parameter is accepted only if a code challenge parameter was present in the authorization request.” During the coordinated disclosure phase, we discovered that at least one party had misinterpreted this directive, understanding it to mean that if the authorization request lacked a code challenge parameter, the code verifier should be disregarded — the exact opposite of what the BCP intended.
Сравнительный анализ между коммерческими и некоммерческими решениями при этом не выявил сильной разницы. Также в ходе раскрытия информации разработчикам были опубликованы две CVE: CVE-2024-23647 и CVE-2024-22258. А представители одного из продуктов вообще не ответили авторам, несмотря на попытки с ними связаться 😃
В заключение авторы указывают, что проблемы были обнаружены в семи из восьми рассмотренных имплементаций (отличились только ребята из Ory). Ну и говорят, что, казалось бы, существующие BCP предоставляют достаточные и описанные меры, но разработчики все еще не следуют этим рекомендациям. А также авторы говорят, что ждут OAuth 2.1 как новый комплексный baseline standard (я все еще несколько пессимистичен, правда, насчет таких взглядов).
#oauth #paper #security
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍1🤔1
401 Unauthorized: аутентификация и не только
Статья "Is Your OAuth Middleware Vulnerable? Evaluating Open-Source Identity Provider's Security" Третья и последняя из опубликованных статей от авторов OAuch, которая вышла в конце 24 года. Публично она пока недоступна, однако по секретным каналам мне удалось…
Кстати про уязвимую проверку redirect URI. Казалось бы, где деньги взять как сравнивать redirect URI, давно известно. Однако мы до сих пор то тут, то там видим, что вектор атаки с использованием подконтрольного атакующему redirect URI с радаров никуда не уходит и исследователи продолжают обнаруживать подходы к эксплуатации подобной атаки.
Недавно вышла статья, где автор как раз обнаружил уязвимость в логике проверки redirect URI у Google Cloud.
В Google Cloud для работы из CLI используется утилита gcloud. Для аутентификации и получения токенов, как это бывает в таких случаях, используется Authorization code grant, при этом для обработки callback-запроса с authorization response gcloud поднимает небольшой веб-сервер на локальном порту, на который и приходит редирект с authorization response.
В таком случае в качестве URL для redirect URI используется так называемый loopback-адрес, условно тот же локалхост (127.0.0.1). Ну и для него из-за динамического порта становится уже чуть сложнее выполнять проверку совпадения адреса с зарегистрированным.
Так вот автор обнаружил различия в механизме парсинга URL между внутренним парсером на стороне серверной части Google Cloud и парсером в браузерах, в частности в Chrome. Соответственно, автор смог скрафтить такой URL, который при проверке на стороне Google Cloud считался валидным, но для Chrome парсился уже иным образом, позволив автору получить редирект с authorization response уже на подконтрольный ему домен.
В общем, статья любопытная, посмотрите сами.
#oauth #security #article
Недавно вышла статья, где автор как раз обнаружил уязвимость в логике проверки redirect URI у Google Cloud.
В Google Cloud для работы из CLI используется утилита gcloud. Для аутентификации и получения токенов, как это бывает в таких случаях, используется Authorization code grant, при этом для обработки callback-запроса с authorization response gcloud поднимает небольшой веб-сервер на локальном порту, на который и приходит редирект с authorization response.
В таком случае в качестве URL для redirect URI используется так называемый loopback-адрес, условно тот же локалхост (127.0.0.1). Ну и для него из-за динамического порта становится уже чуть сложнее выполнять проверку совпадения адреса с зарегистрированным.
Так вот автор обнаружил различия в механизме парсинга URL между внутренним парсером на стороне серверной части Google Cloud и парсером в браузерах, в частности в Chrome. Соответственно, автор смог скрафтить такой URL, который при проверке на стороне Google Cloud считался валидным, но для Chrome парсился уже иным образом, позволив автору получить редирект с authorization response уже на подконтрольный ему домен.
В общем, статья любопытная, посмотрите сами.
#oauth #security #article
Medium
Google Cloud Account Takeover via URL Parsing Confusion
TL;DR
👍1🤔1
401 Unauthorized: аутентификация и не только
Опубликовал результаты исследования любопытного вектора атаки в виде статьи: https://habr.com/ru/articles/880544/ В ней узнаем, что такое «прерывание OAuth flow» и как его применять, затронем использование паттерна Backend‑for‑Frontend и способы реализации…
Тем временем моя статья "Атаки через новый OAuth flow, authorization code injection, и помогут ли HttpOnly, PKCE и BFF" стала победителем в ежегодном конкурсе статей на Хабре Технотекст 7 в номинации "Информационная безопасность" 🥳
Все итоги конкурса: https://habr.com/ru/companies/habr/articles/911650/
Все итоги конкурса: https://habr.com/ru/companies/habr/articles/911650/
🔥24👍6🤔1
Видео с KeyConf24
Keycloak является довольно популярным IAM-решением, поэтому вопросы работы с ним остаются актуальными. Не так давно участвовал в проводимом вместе с русскоязычным Keycloak-сообществом митапе, однако у Keycloak есть сообщества не только в России. Например, вы знали, что последние годы проводится выделенная конференция - KeyConf?
Так доступны видео докладов с прошлой конференции - KeyConf24:
https://www.youtube.com/playlist?list=PL7Azddo9KxKl57kWl_PHV3BNkKNULk4yV
Спикеров и тезисы докладов можно также посмотреть на сайте.
Доклады, думаю, будут все же более интересны работающим именно с Keycloak. Я сам посмотрел пока один общий - "New and Noteworthy in the OAuth World" от Dmitry Telegin.
В нем автор рассказывает про новые (на момент осени 24 года) инициативы в области стандартов:
🏷 OAuth 2.0 for First-Party Applications (draft)
🏷 Transaction Tokens (draft)
🏷 OAuth Identity and Authorization Chaining Across Domains (draft)
🏷 OAuth Client ID Metadata Document
Автор кратко и обзорно проходится по каждому из документов, а также рассказывать о возможностях будущей их поддержки с точки зрения Keycloak. На мой взгляд, как небольшой обзорный доклад может быть вполне интересно послушать, однако именно данное выступление мне лично не очень зашло.
Часть информации не была для меня новой, а часть - особо релевантной. При этом у записи довольно плохой звук и баг с отображением презентации - ближе к концу слайды просто перестали меняться, что тоже не добавило удовольствия =(
Однако это только один доклад из 11, так что, возможно, в прочих можно подчерпнуть что-то более ценное.
#video #iam_general
Keycloak является довольно популярным IAM-решением, поэтому вопросы работы с ним остаются актуальными. Не так давно участвовал в проводимом вместе с русскоязычным Keycloak-сообществом митапе, однако у Keycloak есть сообщества не только в России. Например, вы знали, что последние годы проводится выделенная конференция - KeyConf?
Так доступны видео докладов с прошлой конференции - KeyConf24:
https://www.youtube.com/playlist?list=PL7Azddo9KxKl57kWl_PHV3BNkKNULk4yV
Спикеров и тезисы докладов можно также посмотреть на сайте.
Доклады, думаю, будут все же более интересны работающим именно с Keycloak. Я сам посмотрел пока один общий - "New and Noteworthy in the OAuth World" от Dmitry Telegin.
В нем автор рассказывает про новые (на момент осени 24 года) инициативы в области стандартов:
Автор кратко и обзорно проходится по каждому из документов, а также рассказывать о возможностях будущей их поддержки с точки зрения Keycloak. На мой взгляд, как небольшой обзорный доклад может быть вполне интересно послушать, однако именно данное выступление мне лично не очень зашло.
Часть информации не была для меня новой, а часть - особо релевантной. При этом у записи довольно плохой звук и баг с отображением презентации - ближе к концу слайды просто перестали меняться, что тоже не добавило удовольствия =(
Однако это только один доклад из 11, так что, возможно, в прочих можно подчерпнуть что-то более ценное.
#video #iam_general
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔2
Запись моего доклада "Токены доступа и API gateway: как обеспечить безопасность запросов" с PHDays уже доступна. Посмотреть можно на:
📌 YouTube
📌 VK Видео
📌 Rutube
#api #iam_general #oauth #my_talk
#api #iam_general #oauth #my_talk
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17🤔2❤1🔥1
401 Unauthorized: аутентификация и не только
Запись моего доклада "Токены доступа и API gateway: как обеспечить безопасность запросов" с PHDays уже доступна. Посмотреть можно на: 📌 YouTube 📌 VK Видео 📌 Rutube #api #iam_general #oauth #my_talk
Кузнецов_Токены_доступа_и_API_Gateway.pdf
5 MB
Также прикладываю презентацию с выступления.
🔥12👍1🤔1
Книга "Cloud Native Data Security with OAuth: A Scalable Zero Trust Architecture"
Совсем недавно, вот буквально в марте, вышла новая книга на тему Identity & Access Management. Я уже писал, что интересных книг про IAM знаю совсем немного, поэтому, конечно, обрадовался такому событию.
Книга аффилирована с компанией Curity, ее авторы как раз там и работают. Поскольку ранее я уже отмечал свое положительное впечатление о качестве публикуемых компанией материалов, к книге изначально тоже подходил с определенными надеждами =)
Также у Gary Archer, одного из авторов, очень достойные ответы на Stack Overflow, не раз их встречал.
В посте традиционно для книги указал ссылку на Амазон, однако сразу хочу сказать, что в электронном виде книгу авторы сами раздают бесплатно (подсказка: данные в форме можно указать любые).
В книге четыре принципиальных части:
📚 Part I. Introducing Cloud Native OAuth
📚 Part II. Securing APIs with Tokens
📚Part III. Operating Cloud Native OAuth
📚Part IV. Securing API Clients
Собственно, их и намереваюсь рассмотреть, начав с первой.
Часть 1 | Часть 2 | Часть 3 | Часть 4
#book #iam_general #oauth
Совсем недавно, вот буквально в марте, вышла новая книга на тему Identity & Access Management. Я уже писал, что интересных книг про IAM знаю совсем немного, поэтому, конечно, обрадовался такому событию.
Книга аффилирована с компанией Curity, ее авторы как раз там и работают. Поскольку ранее я уже отмечал свое положительное впечатление о качестве публикуемых компанией материалов, к книге изначально тоже подходил с определенными надеждами =)
Также у Gary Archer, одного из авторов, очень достойные ответы на Stack Overflow, не раз их встречал.
В посте традиционно для книги указал ссылку на Амазон, однако сразу хочу сказать, что в электронном виде книгу авторы сами раздают бесплатно (подсказка: данные в форме можно указать любые).
В книге четыре принципиальных части:
📚 Part I. Introducing Cloud Native OAuth
📚 Part II. Securing APIs with Tokens
📚Part III. Operating Cloud Native OAuth
📚Part IV. Securing API Clients
Собственно, их и намереваюсь рассмотреть, начав с первой.
Часть 1 | Часть 2 | Часть 3 | Часть 4
#book #iam_general #oauth
👍9🤔1
Первая часть обзора книги "Cloud Native Data Security with OAuth: A Scalable Zero Trust Architecture"
В первой главе авторы пробуют ответить на вопрос: “А зачем нам вообще OAuth?”.
И уже с первой страницы главы авторы делают мне приятно и используют понятие “аутентификация запросов”, ставим лайк. А вот сама аргументация “за” использование OAuth здесь не сильно впечатлила:
🔵 Как будто больше маркетинга, чем рациональных доводов
🔵 В доводах указываются вещи, которые я бы не связал напрямую с OAuth
🔵 Не хватило секции “почему не что-то другое”
Ну то есть я, будучи сам сторонником использования OAuth, читая, вижу натянутость приведенных аргументов. Но я-то для себя об этом думал, и у меня есть другие! А вот если читать будет скептически настроенный критик… Илиюный неокрепший ум… Не знаю, в общем.
Тут же авторы приводят пояснение, что они понимают под Cloud Native:
Как говорится, а мужики-то не знают! Интересное определение, да? В общем, приведенное описание Cloud Native здесь не понял, как будто “в общих словах” все.
После вводной главы об основах OAuth и OIDC, в третьей, авторы переходят к понятию API security architecture. Тут мне откликнулась мысль о выделении ключевой триады функций и соответствующих им ключевых компонентов:
1️⃣ Identity & Access Management — Authorization Server
2️⃣ API Management — API Gateway
3️⃣ Entitlement Management — Policy Engine
Я очень солидарен с тем, что в современных системах, говоря о вопросах IAM, мало думать только про “аутентификацию и авторизацию”, как говорили раньше. В том числе в более расширенном смысле на это смотрит и концепция Identity Fabrics, про которую писал ранее (пост 1, пост 2).
Модные названия у такой расширенной области могут быть разными, как разными могут быть и ее границы. Вот такой краткий вариант с выделением трех базовых и понятных функций-компонентов тоже хорош, поскольку позволяет для их рассмотрения абстрагироваться от прочих деталей.
Дальше начинаются действительно интересные главы. В главе четыре предлагается взглянуть на некоторые функции и дизайн данных самого компонента authorization server. Во-первых, хочется сказать, что про это вообще мало пишут, а во-вторых, напомню, что у Curity как раз есть свое IAM-решение, поэтому можно надеяться, что ребята в целом должны знать, о чем говорят.
Авторы обращают внимание на существование различных категорий данных у authorization server. Приведенная конкретно здесь классификация показалась чуть странной, но в целом сама мысль верная. Подумав в эту сторону, мы можем увидеть, что данные различаются своими характеристиками, жизненными циклами, характерами нагрузки и пр. И, например, понять, что для разных данных нам (внезапно) могут понадобиться различные хранилища (СУБД). Для примера можно посмотреть, как аналогичный подход применяют RooX в своем UIDM, используя несколько СУБД, в том числе Tarantool для хранения токенов и сессий.
Говорится о подходах к определению пользовательских данных, которые уместно хранить на стороне authorization server. Рассматривают различные подходы к работе с атрибутами пользователя, в том числе и такой, где сам authorization server может сходить в другой сервис за данными пользователя, которые хранятся там. Я уже писал о кейсе, когда это может быть применимо, разбирая Rich Authorization Requests (RAR).
Также авторы упоминают и про довольно важные вещи вроде управления конфигурациями, мультитенантности и мультирегиональности.
Кстати, пользовательская миграция через SCIM показывается на примере любопытной задачки: вот есть такие-то собранные в кучу данные (AS IS), давайте приведем их к желаемому виду, разделив на identity-данные и бизнес-данные (TO BE). Мне подумалось, что такой кейс может быть здорово рассмотреть в процессе собеседования, чтобы посмотреть, как кандидат смотрит на подобные вопросы. Выглядит пока незаезженно 😈
#book #iam_general #oauth
В первой главе авторы пробуют ответить на вопрос: “А зачем нам вообще OAuth?”.
И уже с первой страницы главы авторы делают мне приятно и используют понятие “аутентификация запросов”, ставим лайк. А вот сама аргументация “за” использование OAuth здесь не сильно впечатлила:
Ну то есть я, будучи сам сторонником использования OAuth, читая, вижу натянутость приведенных аргументов. Но я-то для себя об этом думал, и у меня есть другие! А вот если читать будет скептически настроенный критик… Или
Тут же авторы приводят пояснение, что они понимают под Cloud Native:
Cloud native is a technology approach for operating services and infrastructure in a vendor-neutral way.
Как говорится, а мужики-то не знают! Интересное определение, да? В общем, приведенное описание Cloud Native здесь не понял, как будто “в общих словах” все.
После вводной главы об основах OAuth и OIDC, в третьей, авторы переходят к понятию API security architecture. Тут мне откликнулась мысль о выделении ключевой триады функций и соответствующих им ключевых компонентов:
Я очень солидарен с тем, что в современных системах, говоря о вопросах IAM, мало думать только про “аутентификацию и авторизацию”, как говорили раньше. В том числе в более расширенном смысле на это смотрит и концепция Identity Fabrics, про которую писал ранее (пост 1, пост 2).
Модные названия у такой расширенной области могут быть разными, как разными могут быть и ее границы. Вот такой краткий вариант с выделением трех базовых и понятных функций-компонентов тоже хорош, поскольку позволяет для их рассмотрения абстрагироваться от прочих деталей.
Дальше начинаются действительно интересные главы. В главе четыре предлагается взглянуть на некоторые функции и дизайн данных самого компонента authorization server. Во-первых, хочется сказать, что про это вообще мало пишут, а во-вторых, напомню, что у Curity как раз есть свое IAM-решение, поэтому можно надеяться, что ребята в целом должны знать, о чем говорят.
Авторы обращают внимание на существование различных категорий данных у authorization server. Приведенная конкретно здесь классификация показалась чуть странной, но в целом сама мысль верная. Подумав в эту сторону, мы можем увидеть, что данные различаются своими характеристиками, жизненными циклами, характерами нагрузки и пр. И, например, понять, что для разных данных нам (внезапно) могут понадобиться различные хранилища (СУБД). Для примера можно посмотреть, как аналогичный подход применяют RooX в своем UIDM, используя несколько СУБД, в том числе Tarantool для хранения токенов и сессий.
Говорится о подходах к определению пользовательских данных, которые уместно хранить на стороне authorization server. Рассматривают различные подходы к работе с атрибутами пользователя, в том числе и такой, где сам authorization server может сходить в другой сервис за данными пользователя, которые хранятся там. Я уже писал о кейсе, когда это может быть применимо, разбирая Rich Authorization Requests (RAR).
Также авторы упоминают и про довольно важные вещи вроде управления конфигурациями, мультитенантности и мультирегиональности.
Кстати, пользовательская миграция через SCIM показывается на примере любопытной задачки: вот есть такие-то собранные в кучу данные (AS IS), давайте приведем их к желаемому виду, разделив на identity-данные и бизнес-данные (TO BE). Мне подумалось, что такой кейс может быть здорово рассмотреть в процессе собеседования, чтобы посмотреть, как кандидат смотрит на подобные вопросы. Выглядит пока незаезженно 😈
#book #iam_general #oauth
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥4🤔1
[1/2] Вторая часть обзора книги “Cloud Native Data Security with OAuth”
Продолжаю писать про данную книгу. Также напомню, что ее можно получить бесплатно.
Вторую часть книги авторы посвящают использованию токенов для обеспечения безопасности API и начинают с главы 5 - «Secure API Development».
Авторам нравится идея, когда конечные сервисы работают только с self-contained, JWT токеном доступа (мне такая идея тоже нравится, кстати), а сами clients могут использовать другие, различные временные учетные данные.
Говорят про валидацию JWT, затрагивают проверку подписи и ротацию ключей. Также отмечают, что лучше не забывать про тесты с невалидными JWT, чтобы иметь уверенность, что валидация работает, как надо.
Авторы отделяют проверку JWT от самой проверки авторизации, и далее как раз пишут и про нее. Например, упоминают о возможности использования scopes для «грубой» (coarse) проверки авторизации. При этом пишут, что scopes могут помочь задать некоторые «границы» применения токена, но не предоставляют, естественно, сами по себе полного решения задач проверки авторизации.
В контексте обработки истечения времени жизни токенов говорят про «короткое» время жизни токенов доступа, отмечая, что такие токены живут меньше, чем «users’ sessions». Это любопытно, потому что я как раз таким же образом выводил определение короткого времени жизни в докладе “Refresh token в веб-приложениях: быть или не быть?” (надеюсь, скоро доберусь опубликовать материал в виде статьи).
Переходят к вопросам тестирования. Предлагают подход разделения самого JWT и уже того, что называют «claims principal object» - как модельку уже. Из этого исходит идея, что можно тогда покрывать логику проверки авторизации юнит-тестами, используя в качестве фикстуры различные вариации этого «claims principal object».
Также рассказывают, как можно имитировать OAuth-обвязку для тестирования работы конечного сервиса: создать свою ключевую пару, замокать JWKS URI и настроить сервис на работу с ним. Тогда с приватным ключом из ключевой пары можно наподписывать себе любых токенов, что как раз удобно для различных тестов. Ну и с таким подходом, соответственно, поощряют разработчиков к более частому и легкому запуску тестов изолированно, локально – без необходимости поднимать какие-то еще сервисы для обвязки.
Дальше авторы переходят к вопросам проектирования и использования самих access tokens. Предлагают рассматривать access token как контракт, причем даже если он является непрозрачным (opaque), потому что, например, увеличив длину токена, можно тоже поломать чью-нибудь работу.
Пишут, что scopes не являются полным решением для [проверки] авторизации, однако они как раз формируют область действия для токена (я бы сюда еще добавил и audiences). Соответственно авторы тоже говорят о том, что используя скоупы client может получить access token для конкретных целей, ну и что их всегда стоит ограничивать.
Пишут авторы и про дизайн скоупов, при этом предлагают проектировать их исходя из понятий бизнесовых, нежели чем из технических. И дают совет: можно как источник вдохновения при дизайне скоупов посмотреть, как это сделано в спецификации OIDC.
Упоминая claims, напоминают, что помещая их в токен, authorization server как бы “ручается” за их содержимое, и конечные сервисы будут им доверять. Поэтому важно не помещать непроверенную информацию в содержимое клˈеймов.
Говорят про различные источники данных для клеймов, отмечают и факт, что часто меняющиеся значения не являются хорошими кандидатами на помещение в claims, потому что могут быстро стать неактуальными.
Также в этой главе авторы приводят определенный подход к дизайну scopes и claims, в том числе с учетом дальнейшей эксплуатации и масштабирования.
Затрагивают такую тему, как передача, распространение токенов (token sharing). Кратко разбирают такие подходы, как token exchange и embedding tokens in tokens. Упоминают и про использование токенов доступа при асинхронных операциях: что делать, когда проверка токена может произойти значительно позже отправки сообщения с ним.
(продолжение см. ниже)
#book #iam_general #oauth.
Продолжаю писать про данную книгу. Также напомню, что ее можно получить бесплатно.
Вторую часть книги авторы посвящают использованию токенов для обеспечения безопасности API и начинают с главы 5 - «Secure API Development».
Авторам нравится идея, когда конечные сервисы работают только с self-contained, JWT токеном доступа (мне такая идея тоже нравится, кстати), а сами clients могут использовать другие, различные временные учетные данные.
Говорят про валидацию JWT, затрагивают проверку подписи и ротацию ключей. Также отмечают, что лучше не забывать про тесты с невалидными JWT, чтобы иметь уверенность, что валидация работает, как надо.
Авторы отделяют проверку JWT от самой проверки авторизации, и далее как раз пишут и про нее. Например, упоминают о возможности использования scopes для «грубой» (coarse) проверки авторизации. При этом пишут, что scopes могут помочь задать некоторые «границы» применения токена, но не предоставляют, естественно, сами по себе полного решения задач проверки авторизации.
В контексте обработки истечения времени жизни токенов говорят про «короткое» время жизни токенов доступа, отмечая, что такие токены живут меньше, чем «users’ sessions». Это любопытно, потому что я как раз таким же образом выводил определение короткого времени жизни в докладе “Refresh token в веб-приложениях: быть или не быть?” (надеюсь, скоро доберусь опубликовать материал в виде статьи).
Переходят к вопросам тестирования. Предлагают подход разделения самого JWT и уже того, что называют «claims principal object» - как модельку уже. Из этого исходит идея, что можно тогда покрывать логику проверки авторизации юнит-тестами, используя в качестве фикстуры различные вариации этого «claims principal object».
Также рассказывают, как можно имитировать OAuth-обвязку для тестирования работы конечного сервиса: создать свою ключевую пару, замокать JWKS URI и настроить сервис на работу с ним. Тогда с приватным ключом из ключевой пары можно наподписывать себе любых токенов, что как раз удобно для различных тестов. Ну и с таким подходом, соответственно, поощряют разработчиков к более частому и легкому запуску тестов изолированно, локально – без необходимости поднимать какие-то еще сервисы для обвязки.
Дальше авторы переходят к вопросам проектирования и использования самих access tokens. Предлагают рассматривать access token как контракт, причем даже если он является непрозрачным (opaque), потому что, например, увеличив длину токена, можно тоже поломать чью-нибудь работу.
Пишут, что scopes не являются полным решением для [проверки] авторизации, однако они как раз формируют область действия для токена (я бы сюда еще добавил и audiences). Соответственно авторы тоже говорят о том, что используя скоупы client может получить access token для конкретных целей, ну и что их всегда стоит ограничивать.
Пишут авторы и про дизайн скоупов, при этом предлагают проектировать их исходя из понятий бизнесовых, нежели чем из технических. И дают совет: можно как источник вдохновения при дизайне скоупов посмотреть, как это сделано в спецификации OIDC.
Упоминая claims, напоминают, что помещая их в токен, authorization server как бы “ручается” за их содержимое, и конечные сервисы будут им доверять. Поэтому важно не помещать непроверенную информацию в содержимое клˈеймов.
Говорят про различные источники данных для клеймов, отмечают и факт, что часто меняющиеся значения не являются хорошими кандидатами на помещение в claims, потому что могут быстро стать неактуальными.
Также в этой главе авторы приводят определенный подход к дизайну scopes и claims, в том числе с учетом дальнейшей эксплуатации и масштабирования.
Затрагивают такую тему, как передача, распространение токенов (token sharing). Кратко разбирают такие подходы, как token exchange и embedding tokens in tokens. Упоминают и про использование токенов доступа при асинхронных операциях: что делать, когда проверка токена может произойти значительно позже отправки сообщения с ним.
(продолжение см. ниже)
#book #iam_general #oauth.
🔥4❤1👍1🤔1
[2/2] Вторая часть обзора книги “Cloud Native Data Security with OAuth”
Далее переходят к вопросам безопасного использования токенов доступа. Один из авторов, Michal Trojanowski, кстати, ранее так и писал в одной из своих статей:
Авторы пишут про различные форматы токенов доступа и про работу с ними: интроспекция, token exchange, the split token pattern.
Говоря про разные подходы, которыми можно обезопасить токены доступа, упоминают и подход ограничения их области действия до минимально необходимой - то, о чем нам говорит принцип least privilege.
Затем авторы решают рассказать про использование API Gateway и service mesh. Приводят краткую справку, как и что устроено в контексте Kubernetes, упоминая про Ingress и Gateway API.
Авторы пишут, что на их взгляд, ключевым фактором при выборе API Gateway является расширяемость, подводя к дальнейшему рассмотрению работы с токенами доступа, того что называют “token termination”.
Такая token termination в видении авторов состоит из двух задач:
🔵 валидация входящих временных учетных данных
🔵 трансляция их в JWT access token для конечных сервисов.
А дальше авторы как раз разбираю эти задачи для непрозрачных токенов доступа, cookies и sender-constrained токенов.
Говорится:
В конце главы читателя ждет небольшой пример использования API Gateway (авторы используют Kong) в Kubernetes. Также здесь авторы демонстрируют пример использования ранее упомянутой расширяемости: пишут плагин на Lua, чтобы реализовать схему с двумя видами токенов доступа (как они это называют - the Phantom Token Approach).
На протяжении данной главы авторы на это несколько раз намекали, а здесь уже прямо показывают, что реализовывать такую схему они предлагают через RFC 9701 JSON Web Token (JWT) Response for OAuth Token Introspection. Однако мне не очень нравится использование данного RFC для решения обозначенной задачи:
🔵 Здесь получаете не отдельный токен доступа в виде JWT, а обернутый в JWT тот же ответ от introspection endpoint
🔵 Таким образом два представления токена доступа полноценно не “развязать”: полученный JWT не ограничить отдельно по времени жизни или области действия
🔵 Сами авторы RFC пишут, что возвращаемый здесь JWT “is not an alternative representation of the introspected access token and is not intended to be used as an access token”
В девятой главе авторы переходят к рассмотрению вопросов контроля доступа. Рассматривают кратко такие модели контроля доступа, как RBAC, ReBAC, ABAC (а еще упоминают понятие RAdAC).
Понравилось высказывание о том, что недостаточно только лишь хорошо продумать правила доступа, важно не упускать из фокуса и процесс наделения субъектов полномочиями (например, назначение ролей пользователям). Таким образом подчеркивают, что нужно стараться не допускать “overprivileged accounts”.
Интересна и часть, где авторы описывают преимущества использования выделенной entitlement management system (EMS):
🔵 Flexibility (API работают только с предоставленным результатом, саму логику контроля доступа можно изменять, не ломая их)
🔵 Auditability (имеем события аудита как для применения политик, так и их для изменения)
🔵 Security agility (отделение ЖЦ политик доступа от ЖЦ конечных сервисов)
🔵 Quality assurance via policy as code (если политики прописываются отдельно, сами сервисы могут не тестировать их внутреннюю логику, а покрывать только возможные исходы)
В завершение кратко упоминают про P*P-концепцию и рассказывают про использования Open Policy Agent (OPA), заодно показывая небольшой пример использования языка Rego.
#book #iam_general #oauth.
Далее переходят к вопросам безопасного использования токенов доступа. Один из авторов, Michal Trojanowski, кстати, ранее так и писал в одной из своих статей:
While secure flows are essential, they should be complemented by a keen focus on access tokens.
Авторы пишут про различные форматы токенов доступа и про работу с ними: интроспекция, token exchange, the split token pattern.
Говоря про разные подходы, которыми можно обезопасить токены доступа, упоминают и подход ограничения их области действия до минимально необходимой - то, о чем нам говорит принцип least privilege.
Затем авторы решают рассказать про использование API Gateway и service mesh. Приводят краткую справку, как и что устроено в контексте Kubernetes, упоминая про Ingress и Gateway API.
Авторы пишут, что на их взгляд, ключевым фактором при выборе API Gateway является расширяемость, подводя к дальнейшему рассмотрению работы с токенами доступа, того что называют “token termination”.
Такая token termination в видении авторов состоит из двух задач:
А дальше авторы как раз разбираю эти задачи для непрозрачных токенов доступа, cookies и sender-constrained токенов.
Говорится:
We have seen that your overall API security is distributed between the API gateway APIs, and possibly additional components such as service meshes.
В конце главы читателя ждет небольшой пример использования API Gateway (авторы используют Kong) в Kubernetes. Также здесь авторы демонстрируют пример использования ранее упомянутой расширяемости: пишут плагин на Lua, чтобы реализовать схему с двумя видами токенов доступа (как они это называют - the Phantom Token Approach).
На протяжении данной главы авторы на это несколько раз намекали, а здесь уже прямо показывают, что реализовывать такую схему они предлагают через RFC 9701 JSON Web Token (JWT) Response for OAuth Token Introspection. Однако мне не очень нравится использование данного RFC для решения обозначенной задачи:
В девятой главе авторы переходят к рассмотрению вопросов контроля доступа. Рассматривают кратко такие модели контроля доступа, как RBAC, ReBAC, ABAC (а еще упоминают понятие RAdAC).
Понравилось высказывание о том, что недостаточно только лишь хорошо продумать правила доступа, важно не упускать из фокуса и процесс наделения субъектов полномочиями (например, назначение ролей пользователям). Таким образом подчеркивают, что нужно стараться не допускать “overprivileged accounts”.
Интересна и часть, где авторы описывают преимущества использования выделенной entitlement management system (EMS):
В завершение кратко упоминают про P*P-концепцию и рассказывают про использования Open Policy Agent (OPA), заодно показывая небольшой пример использования языка Rego.
#book #iam_general #oauth.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6🤔4❤3👍3
Третья часть обзора книги “Cloud Native Data Security with OAuth”
Говорим про часть III - “Operating Cloud Native OAuth”. Начинается она с главы 10 Workload Identities.
Здесь нам говорят: “OAuth alone does not solve all API security problems”. И предлагают рассмотреть, как могут быть удовлетворены требования вида обеспечения конфиденциальности трафика и ограничения возможности выполнять действия от лица сервисов даже при утечке их секретов (hardening, PoP).
Поэтому предлагают поговорить про workload identities. Авторы понимают под workload “a piece of software such as a microservice running in Kubernetes”.
Это можно сравнить с другими определениями. Так draft Workload Identity in a Multi System Environment (WIMSE) Architecture определяет workload как “a running instance of software executing for a specific purpose”. А концепция SPIFFE при этом дает более широкое определение.
Соответственно workload identity называют набор атрибутов, которые однозначно описывают workload. А под workload credential понимают некоторое криптографически проверяемое утверждение (assertion) для этой workload identity. При этом авторы отмечают, что здесь часто используют эти два понятия (wl identity и wl credential) взаимозаменяемо.
Говоря о том, а как workloads могут получить свою identity, отмечают, что облачные провайдеры могут назначать каждому workload свой идентификатор и позволять получать credentials, чтобы подтвердить свою identity в запросах. Также отмечают возможность использования service accounts в Kubernetes и SPIFFE.
В рамках данной главы авторы говорят о решении двух задач:
1️⃣ Надежное представление identity для workload в запросах с использованием некоего credential (JWT или X.509 сертификата)
2️⃣ Шифрование трафика для обеспечения его конфиденциальности
Авторы отмечают слабые стороны “статических” секретов, например, для аутентификации client у authorization server или для соединения с БД.
Из этого и исходят два основных кейса применения workload credentials в видении авторов:
1️⃣ Как альтернатива некоему секрету для аутентификации (например, вместо client secret в OAuth)
2️⃣ Для “апгрейда” bearer-токенов до sender-constrained
Так авторы описывают идею подхода, где сочетают OAuth token exchange и workload identities, чтобы как раз получать уже sender-constrained access-токены. И, кстати, рекомендуют использовать как раз RFC 7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants вместо стандартных client secrets, если ваш authorization server такое поддерживает.
При этом авторы не рассматривают кейс использования workload identities для аутентификации запросов между самими workloads. Судя по предложенной концепции, для service-to-service (wl-2-wl) взаимодействия авторы безальтернативно предлагают использовать OAuth access tokens, что, на мой взгляд, спорно.
Workload credentials не являются заменой access-токенов (и вообще имеют другое значение), сами концепции устроены по-разному. Однако для задачи аутентификации запросов они как раз могут быть использованы.
В этой части есть еще 11 глава - Managing a Cloud Native Authorization Server, но в ней что-то прям нечего выделить.
Здесь авторы хотели рассказать про подход к деплою, удовлетворение НФТ, сопровождение для компонента authorization server. Темы сами по себе безусловно важные, но требующие достаточно много времени и деталей, чтобы их раскрыть. А здесь получилось как будто по верхам все и местами сумбурно.
Так у книги остается последняя часть - Securing API Clients, про которую напишу уже следующий пост.
#book #iam_general #oauth
Говорим про часть III - “Operating Cloud Native OAuth”. Начинается она с главы 10 Workload Identities.
Здесь нам говорят: “OAuth alone does not solve all API security problems”. И предлагают рассмотреть, как могут быть удовлетворены требования вида обеспечения конфиденциальности трафика и ограничения возможности выполнять действия от лица сервисов даже при утечке их секретов (hardening, PoP).
Поэтому предлагают поговорить про workload identities. Авторы понимают под workload “a piece of software such as a microservice running in Kubernetes”.
Это можно сравнить с другими определениями. Так draft Workload Identity in a Multi System Environment (WIMSE) Architecture определяет workload как “a running instance of software executing for a specific purpose”. А концепция SPIFFE при этом дает более широкое определение.
Соответственно workload identity называют набор атрибутов, которые однозначно описывают workload. А под workload credential понимают некоторое криптографически проверяемое утверждение (assertion) для этой workload identity. При этом авторы отмечают, что здесь часто используют эти два понятия (wl identity и wl credential) взаимозаменяемо.
Говоря о том, а как workloads могут получить свою identity, отмечают, что облачные провайдеры могут назначать каждому workload свой идентификатор и позволять получать credentials, чтобы подтвердить свою identity в запросах. Также отмечают возможность использования service accounts в Kubernetes и SPIFFE.
В рамках данной главы авторы говорят о решении двух задач:
1️⃣ Надежное представление identity для workload в запросах с использованием некоего credential (JWT или X.509 сертификата)
2️⃣ Шифрование трафика для обеспечения его конфиденциальности
Авторы отмечают слабые стороны “статических” секретов, например, для аутентификации client у authorization server или для соединения с БД.
Из этого и исходят два основных кейса применения workload credentials в видении авторов:
1️⃣ Как альтернатива некоему секрету для аутентификации (например, вместо client secret в OAuth)
2️⃣ Для “апгрейда” bearer-токенов до sender-constrained
Так авторы описывают идею подхода, где сочетают OAuth token exchange и workload identities, чтобы как раз получать уже sender-constrained access-токены. И, кстати, рекомендуют использовать как раз RFC 7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants вместо стандартных client secrets, если ваш authorization server такое поддерживает.
При этом авторы не рассматривают кейс использования workload identities для аутентификации запросов между самими workloads. Судя по предложенной концепции, для service-to-service (wl-2-wl) взаимодействия авторы безальтернативно предлагают использовать OAuth access tokens, что, на мой взгляд, спорно.
Workload credentials не являются заменой access-токенов (и вообще имеют другое значение), сами концепции устроены по-разному. Однако для задачи аутентификации запросов они как раз могут быть использованы.
В этой части есть еще 11 глава - Managing a Cloud Native Authorization Server, но в ней что-то прям нечего выделить.
Здесь авторы хотели рассказать про подход к деплою, удовлетворение НФТ, сопровождение для компонента authorization server. Темы сами по себе безусловно важные, но требующие достаточно много времени и деталей, чтобы их раскрыть. А здесь получилось как будто по верхам все и местами сумбурно.
Так у книги остается последняя часть - Securing API Clients, про которую напишу уже следующий пост.
#book #iam_general #oauth
🤔4👍2
Как “превратить” OIDC в SAML
Как SAML, так и OIDC решают одну задачу: реализацию SSO, при котором пользователь выполняет аутентификацию только в одном месте (IdP/OP), а затем может использовать SSO-сессию для передачи приложениям (SP/RP), доверяющим IdP/OP, некоторого утверждения о своей identity.
При этом довольно часто мы думаем, что реализуемые ими протоколы принципиально отличаются, и иногда их особенности даже могут определять выбор того или иного подхода.
Так, например, одним из принципиальных отличий могут быть каналы взаимодействия в процессе SSO. SAML использует front-channel способ передачи информации об identity (чисто технически существует и back-channel binding, но используется он крайне редко и не везде поддерживается), в то время как OIDC в “классическом” Authorization code flow для confidential client использует back-channel взаимодействие.
В этом они действительно могут различаться: когда SAML опирается всецело на передачу assertion через браузер пользователя - который здесь является своеобразным связующим звеном - OIDC использует back-channel запрос от приложения, в ответ на который и возвращается id_token.
Но что если мы захотим сделать наш OIDC flow максимально похожим на распространенный SAML POST Binding? Давайте попробуем провести мысленный эксперимент.
В таком случае мы можем использовать OIDC Implicit flow вместе с form post response mode.
Важно подчеркнуть, что Implicit flow в контексте OIDC отличается от Implicit grant, определяемого в OAuth 2.0. В OIDC, используя именно
Итак, теперь попробуем сравнить SAML POST Binding с получающимся подходом:
1. В SAML у нас front-channel взаимодействие с автоотправкой assertion из формы. С использованием
2. В SAML мы можем подписать AuthnRequest. В OIDC мы можем использовать JAR для подписи authorization request
3. В SAML мы можем подписать возвращаемый assertion. В OIDC мы можем использовать JARM для подписи authorization response
4. В SAML мы можем использовать шифрование для assertion. В OIDC мы можем снова использовать для этого JARM или же обернуть ID token в JWE (про JWS и JWE писал тут)
5. В SAML мы можем использовать InResponseTo для связи SAMLRequest (AuthnRequest) с SAMLResponse (assertion). В OIDC мы можем использовать state/nonce
Итого: рассматриваемая схема фактически повторяет SAML POST Binding, причем с поддержкой всех дополнений к нему, вроде подписи и шифрования. Вот так с помощью нехитрых приспособлений, можно “превратить” OIDC в SAML. Но зачем?..
Ладно, на самом деле, в каждой шутке есть доля правды. Задумался в очередной раз о таком сходстве я в контексте размышлений о применимости OIDC Implicit flow в сочетании с form_post response mode для одного довольно специфичного случая.
Подход может быть полезен, когда у приложения client есть и серверная, и клиентская части, но при этом сетевой связности между бэкендом приложения и authorization server нет. Например, они находятся в разных сетевых зонах, но оба могут взаимодействовать с сегментом сети, в котором находится устройство пользователя.
И вот здесь, как сейчас видится, наличие у приложения серверной части дает выигрыш в использовании OIDC Implicit flow + form post response mode (даже без наворотов вида JAR/JARM) по сравнению с тем же Authorization code flow для public client.
Кстати, упоминания использования OIDC Implicit flow с form_post response mode можно встретить в документации у Auth0 и MS Entra ID, а также в 6 главе книги "Solving Identity Management in Modern Applications", обзор на которую публиковал ранее.
#iam_general #oauth
Как SAML, так и OIDC решают одну задачу: реализацию SSO, при котором пользователь выполняет аутентификацию только в одном месте (IdP/OP), а затем может использовать SSO-сессию для передачи приложениям (SP/RP), доверяющим IdP/OP, некоторого утверждения о своей identity.
При этом довольно часто мы думаем, что реализуемые ими протоколы принципиально отличаются, и иногда их особенности даже могут определять выбор того или иного подхода.
Так, например, одним из принципиальных отличий могут быть каналы взаимодействия в процессе SSO. SAML использует front-channel способ передачи информации об identity (чисто технически существует и back-channel binding, но используется он крайне редко и не везде поддерживается), в то время как OIDC в “классическом” Authorization code flow для confidential client использует back-channel взаимодействие.
В этом они действительно могут различаться: когда SAML опирается всецело на передачу assertion через браузер пользователя - который здесь является своеобразным связующим звеном - OIDC использует back-channel запрос от приложения, в ответ на который и возвращается id_token.
Но что если мы захотим сделать наш OIDC flow максимально похожим на распространенный SAML POST Binding? Давайте попробуем провести мысленный эксперимент.
В таком случае мы можем использовать OIDC Implicit flow вместе с form post response mode.
Важно подчеркнуть, что Implicit flow в контексте OIDC отличается от Implicit grant, определяемого в OAuth 2.0. В OIDC, используя именно
response_type=id_token, клиент получает в authorization response только ID token, что устраняет риски, связанные с передачей access token через браузер. При этом сам ID token по умолчанию возвращается в URI fragment, однако с использованием response_mode=form_post мы можем передать его в теле POST-запроса со страницы самого authorization server, тем самым устраняя и этот недостаток.Итак, теперь попробуем сравнить SAML POST Binding с получающимся подходом:
1. В SAML у нас front-channel взаимодействие с автоотправкой assertion из формы. С использованием
response_type=id_token&response_mode=form_post мы получаем идентичный механизм отправки ID token2. В SAML мы можем подписать AuthnRequest. В OIDC мы можем использовать JAR для подписи authorization request
3. В SAML мы можем подписать возвращаемый assertion. В OIDC мы можем использовать JARM для подписи authorization response
4. В SAML мы можем использовать шифрование для assertion. В OIDC мы можем снова использовать для этого JARM или же обернуть ID token в JWE (про JWS и JWE писал тут)
5. В SAML мы можем использовать InResponseTo для связи SAMLRequest (AuthnRequest) с SAMLResponse (assertion). В OIDC мы можем использовать state/nonce
Итого: рассматриваемая схема фактически повторяет SAML POST Binding, причем с поддержкой всех дополнений к нему, вроде подписи и шифрования. Вот так с помощью нехитрых приспособлений, можно “превратить” OIDC в SAML. Но зачем?..
Ладно, на самом деле, в каждой шутке есть доля правды. Задумался в очередной раз о таком сходстве я в контексте размышлений о применимости OIDC Implicit flow в сочетании с form_post response mode для одного довольно специфичного случая.
Подход может быть полезен, когда у приложения client есть и серверная, и клиентская части, но при этом сетевой связности между бэкендом приложения и authorization server нет. Например, они находятся в разных сетевых зонах, но оба могут взаимодействовать с сегментом сети, в котором находится устройство пользователя.
И вот здесь, как сейчас видится, наличие у приложения серверной части дает выигрыш в использовании OIDC Implicit flow + form post response mode (даже без наворотов вида JAR/JARM) по сравнению с тем же Authorization code flow для public client.
Кстати, упоминания использования OIDC Implicit flow с form_post response mode можно встретить в документации у Auth0 и MS Entra ID, а также в 6 главе книги "Solving Identity Management in Modern Applications", обзор на которую публиковал ранее.
#iam_general #oauth
👍8🔥3🤔1