Web message response mode, и receiver origin vs redirect URI
Итак, предыдущий пост мы закончили на мысли про различие redirect URI и receiver origin.
Действительно, в случае web message response mode доступность authorization response ограничивается в рамках origin. Так при наличии возможности выполнения вредоносного JS на любой из страниц приложения с тем же origin атакующий действительно сможет получить отправляемые authorization server в postMessage-сообщении параметры authorization response.
Однако насколько верно утверждение о том, что при использовании redirect-based flows атакующий сможет "дотянуться" до authorization response только при внедрении кода в саму страницу redirect URI?
Все мы знаем, что выделенная страница redirect URI дарована нам для того, чтобы мы могли держать ее настолько пустой, насколько это возможно (даже аналитика может быть под вопросом). Это хорошо и правильно. Но достаточно ли этого, чтобы сказать, что authorization response теперь недоступен атакующему, "поселившемуся" в браузере у пользователя? Увы, нет.
На самом деле, ограничение идет в рамках того же самого origin, а не какого-то конкретного пути.
Основная суть в подобных атаках заключается в вызове тем или иным способом authorization request в браузере пользователя с последующим доступом к параметрам authorization response. Действуя в рамках одного origin, атакующий имеет и другие, помимо установки обработчика событий на получение событий "message", способы это сделать. Например, используя iframe или новое окно.
Как известно, в современных браузерах существует защитный механизм Same-origin policy (SOP), который ограничивает взаимодействие страниц, имеющих различные origins.
Таким образом, если мы, например, находясь на странице
Если атакующий в браузере пользователя создаст iframe или откроет новое окно c адресом authorization request, после выполнения редиректа на адрес redirect URI origin у страницы в окне/фрейме изменится на совпадающий с origin страницы родительского окна. Это и позволит атакующему получить доступ к объекту location для извлечения из него параметров authorization response, поскольку такое поведение допустимо в рамках SOP.
Таким образом фактически различие есть только в том, что для случая с web message мы это осознаем более явно, а для redirect-based flows об этом как будто вообще не задумываемся. А суть в целом одна: модель безопасности в браузерах основана не на путях (paths), а на origins.
Тем не менее я все равно настороженно отношусь к использованию postMessage. Это для меня является некоторой аналогией загрузки файлов, но из мира фронтенда: если можно обойтись без этого, то лучше так и сделать. Иначе слишком много мест, где можно обжечься.
#oauth
Итак, предыдущий пост мы закончили на мысли про различие redirect URI и receiver origin.
Действительно, в случае web message response mode доступность authorization response ограничивается в рамках origin. Так при наличии возможности выполнения вредоносного JS на любой из страниц приложения с тем же origin атакующий действительно сможет получить отправляемые authorization server в postMessage-сообщении параметры authorization response.
Однако насколько верно утверждение о том, что при использовании redirect-based flows атакующий сможет "дотянуться" до authorization response только при внедрении кода в саму страницу redirect URI?
Все мы знаем, что выделенная страница redirect URI дарована нам для того, чтобы мы могли держать ее настолько пустой, насколько это возможно (даже аналитика может быть под вопросом). Это хорошо и правильно. Но достаточно ли этого, чтобы сказать, что authorization response теперь недоступен атакующему, "поселившемуся" в браузере у пользователя? Увы, нет.
На самом деле, ограничение идет в рамках того же самого origin, а не какого-то конкретного пути.
Основная суть в подобных атаках заключается в вызове тем или иным способом authorization request в браузере пользователя с последующим доступом к параметрам authorization response. Действуя в рамках одного origin, атакующий имеет и другие, помимо установки обработчика событий на получение событий "message", способы это сделать. Например, используя iframe или новое окно.
Как известно, в современных браузерах существует защитный механизм Same-origin policy (SOP), который ограничивает взаимодействие страниц, имеющих различные origins.
Таким образом, если мы, например, находясь на странице
https://alice.com, откроем новое окно с origin https://bob.com, мы не будем иметь доступа к его содержимому, включая объект location. Здесь на помощь приходит лежащая в основе подобных OAuth flow redirect-based природа callback.Если атакующий в браузере пользователя создаст iframe или откроет новое окно c адресом authorization request, после выполнения редиректа на адрес redirect URI origin у страницы в окне/фрейме изменится на совпадающий с origin страницы родительского окна. Это и позволит атакующему получить доступ к объекту location для извлечения из него параметров authorization response, поскольку такое поведение допустимо в рамках SOP.
Таким образом фактически различие есть только в том, что для случая с web message мы это осознаем более явно, а для redirect-based flows об этом как будто вообще не задумываемся. А суть в целом одна: модель безопасности в браузерах основана не на путях (paths), а на origins.
Тем не менее я все равно настороженно отношусь к использованию postMessage. Это для меня является некоторой аналогией загрузки файлов, но из мира фронтенда: если можно обойтись без этого, то лучше так и сделать. Иначе слишком много мест, где можно обжечься.
#oauth
🤔1
Кто хотел узнать, как устроена аутентификация на портале разработчика Spotify 🙋♂️?
Ранее уже упоминали использование web message response mode, а developer.spotify.com как раз использует таковой. Поэтому сегодня в рубрике "а как у них" рассмотрим использование подобного response mode на реальном примере: https://telegra.ph/Autentifikaciya-na-developerspotifycom-01-22
А вообще полезно бывает обращать внимание на реализации в разных приложениях, пусть и с black box подходом: можно получить больше понимания, что происходит вокруг, какие практики и подходы применяются, подмечая как плюсы, так и минусы.
#oauth
Ранее уже упоминали использование web message response mode, а developer.spotify.com как раз использует таковой. Поэтому сегодня в рубрике "а как у них" рассмотрим использование подобного response mode на реальном примере: https://telegra.ph/Autentifikaciya-na-developerspotifycom-01-22
А вообще полезно бывает обращать внимание на реализации в разных приложениях, пусть и с black box подходом: можно получить больше понимания, что происходит вокруг, какие практики и подходы применяются, подмечая как плюсы, так и минусы.
#oauth
Telegraph
Аутентификация на developer.spotify.com
Если мы пользовались Spotify в браузере, то зайдя на портал, можем сразу обнаружить себя аутентифицированными. Первичный authorization request выполняется не с помощью редиректа, а через встройку "невидимого" iframe с подготовленным URL authorization request:…
🤔2👍1
ecom.teсh x keycloak community meetup
13 марта выступаю на митапе у ребят из ecom.tech, организованного совместно с русскоязычным keycloak-сообществом.
Моя тема идет в самом начале и стартует сразу в 18:00.
Поднимем вопрос о том, нужно ли использовать refresh-токены в веб-приложениях, и если нужно, то каким именно образом.
Рассмотрим саму проблематику и выделим основную задачу, которую как раз обычно требуется решить. Обсудим, какие подходы здесь вообще применимы (спойлер: не только использование refresh-токенов), и поговорим про сами подобные токены: что это, зачем задумывались и как можно их использовать. А также сравним рассмотренные подходы с точки зрения информационной безопасности.
Звучит, конечно, объемно и амбициозно для отведенного получаса, но постараемся охватить по-максимуму 😉
Когда: 13 марта, 18:00–20:15 МСК
Формат: online
Всего будет 3 темы:
🔵 18:00-18:45 — «Refresh token в веб-приложениях: быть или не быть?» (как раз моё выступление)
🔵 18:45-19:30 — «Тернистый путь OAuth: от 2.0 к 2.1», Ирина Блажина, архитектор ИБ в Оператор Газпром ИД, co-owner Solutions of Security. Cпециализация на архитектуре для ИБ на базе решений FW, Proxy, NGFW, IDM, IAM, API-Gateway, IDS/IPS и др.
🔵 19:30-20:15 — «Безопасность микросервисов: как защититься от уязвимостей аутентификации», Алексей Морозов, руководитель AppSec в ecom.teсh
Так что приходите, надеюсь, будет полезно и интересно.
Бесплатно и без смс, но предварительная регистрация все же нужна.
#my_talk #oauth #announce
13 марта выступаю на митапе у ребят из ecom.tech, организованного совместно с русскоязычным keycloak-сообществом.
Моя тема идет в самом начале и стартует сразу в 18:00.
Поднимем вопрос о том, нужно ли использовать refresh-токены в веб-приложениях, и если нужно, то каким именно образом.
Рассмотрим саму проблематику и выделим основную задачу, которую как раз обычно требуется решить. Обсудим, какие подходы здесь вообще применимы (спойлер: не только использование refresh-токенов), и поговорим про сами подобные токены: что это, зачем задумывались и как можно их использовать. А также сравним рассмотренные подходы с точки зрения информационной безопасности.
Звучит, конечно, объемно и амбициозно для отведенного получаса, но постараемся охватить по-максимуму 😉
Когда: 13 марта, 18:00–20:15 МСК
Формат: online
Всего будет 3 темы:
Так что приходите, надеюсь, будет полезно и интересно.
Бесплатно и без смс, но предварительная регистрация все же нужна.
#my_talk #oauth #announce
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8👏3
Статья «Account hijacking using “dirty dancing” in sign-in OAuth-flows»
Сегодня хочу рассказать про статью Account hijacking using “dirty dancing” in sign-in OAuth-flows от исследователя Frans Rosén. Статья вышла еще в 2022 году, однако я с ней ознакомился только в начале данного года. Материал полезный, но мне показалось, что читается прям тяжело: возможно, из-за манеры повествования или из-за обилия тонкостей работы клиентских частей в браузере.
Сначала для затравки в статье кратко рассматриваются основные response types и response modes в OAuth. Далее автор рассказывает, как начал искать уязвимости, связанные с postMessage, и даже применил интересную на тот момент технику: сделал расширение для Chrome для упрощения анализа.
Разбираются тактики для прерывания OAuth flow, чтобы предотвратить использование authorization response (и атакующий мог его использовать сам). Или, как автор их называет, "non-happy paths".
Среди них:
1. Передача невалидного значения state
2. Изменение response type/response mode для authorization request
3. Изменения регистра для redirect URI
4. Расширение пути (path) для значения redirect URI
5. Добавление query-параметров к значению redirect URI
6. Использование добавленных, но "забытых" redirect URI
Кстати, отмечается полезная деталь для случаев с изменением redirect URI:
В абзаце допущена небольшая ошибка: конечно, параметр redirect_uri передается т.н. identity provider (aka authorization server), а не "service-provider", как указано, но суть в целом отражена верно. Интересно это отметить, потому что в OAuth 2.1 этот параметр как раз исключен из token request с любопытным обоснованием.
Далее автор пишет, что собрал набор сайтов с такими non-happy paths и стал их исследовать дальше. Производится категоризация URL-leaking gadgets - так автор называет различные методы утечки URL c параметрами authorization response.
1. postMessage-listeners, которые не проверяют origin и могут вернуть значение location.href назад в parent.window
2. Кейс Reddit: XSS на стороннем домене, поведение которого отражает URL с authorization response с основного домена
3. Third-party скрипты, которые исполняются на странице redirect URI и могут передать куда-либо значение URL с authorization response
Также автор упоминает еще один теоретический гаджет, применения которого он не встретил: postMessage-listener, который проксирует полученные сообщения своему opener.
В заключении автор приходит к выводу, что для защиты от подобных атак, страница, которая получает authorization response (redirect URI), не должна содержать third-party ресурсы или ссылки на сторонние сайты. Также говорится о подходе с ограничением использования только необходимых response types/response modes.
При этом автор справедливо отмечает, что использование PKCE не защищает от таких атак.
____
В итоге для меня наиболее ценным стало описание способов для прерывания OAuth flow: я не думал в подобном ключе про такие тактики, а про некоторые из них и не знал совсем. Также импонирует итоговый посыл автора про ограничение использования third-party скриптов на страницах redirect URI и про лимиты в защите, предоставляемой PKCE.
#article #security #oauth
Сегодня хочу рассказать про статью Account hijacking using “dirty dancing” in sign-in OAuth-flows от исследователя Frans Rosén. Статья вышла еще в 2022 году, однако я с ней ознакомился только в начале данного года. Материал полезный, но мне показалось, что читается прям тяжело: возможно, из-за манеры повествования или из-за обилия тонкостей работы клиентских частей в браузере.
Сначала для затравки в статье кратко рассматриваются основные response types и response modes в OAuth. Далее автор рассказывает, как начал искать уязвимости, связанные с postMessage, и даже применил интересную на тот момент технику: сделал расширение для Chrome для упрощения анализа.
Разбираются тактики для прерывания OAuth flow, чтобы предотвратить использование authorization response (и атакующий мог его использовать сам). Или, как автор их называет, "non-happy paths".
Среди них:
1. Передача невалидного значения state
2. Изменение response type/response mode для authorization request
3. Изменения регистра для redirect URI
4. Расширение пути (path) для значения redirect URI
5. Добавление query-параметров к значению redirect URI
6. Использование добавленных, но "забытых" redirect URI
Кстати, отмечается полезная деталь для случаев с изменением redirect URI:
Please also note that using response_type=code this quirk is harder to exploit. In a proper OAuth-dance using code, in the last step to acquire the access token from the service provider, the redirect_uri must also be provided for validation to the service-provider. If the redirect_uri that was used in the dance is mismatching the value that the website sends to the provider, no access token will be issued. However, using any other response type, like token or id_token this last-step validation is not needed since the token was provided directly in the redirection.
В абзаце допущена небольшая ошибка: конечно, параметр redirect_uri передается т.н. identity provider (aka authorization server), а не "service-provider", как указано, но суть в целом отражена верно. Интересно это отметить, потому что в OAuth 2.1 этот параметр как раз исключен из token request с любопытным обоснованием.
Далее автор пишет, что собрал набор сайтов с такими non-happy paths и стал их исследовать дальше. Производится категоризация URL-leaking gadgets - так автор называет различные методы утечки URL c параметрами authorization response.
1. postMessage-listeners, которые не проверяют origin и могут вернуть значение location.href назад в parent.window
2. Кейс Reddit: XSS на стороннем домене, поведение которого отражает URL с authorization response с основного домена
3. Third-party скрипты, которые исполняются на странице redirect URI и могут передать куда-либо значение URL с authorization response
Также автор упоминает еще один теоретический гаджет, применения которого он не встретил: postMessage-listener, который проксирует полученные сообщения своему opener.
В заключении автор приходит к выводу, что для защиты от подобных атак, страница, которая получает authorization response (redirect URI), не должна содержать third-party ресурсы или ссылки на сторонние сайты. Также говорится о подходе с ограничением использования только необходимых response types/response modes.
При этом автор справедливо отмечает, что использование PKCE не защищает от таких атак.
____
В итоге для меня наиболее ценным стало описание способов для прерывания OAuth flow: я не думал в подобном ключе про такие тактики, а про некоторые из них и не знал совсем. Также импонирует итоговый посыл автора про ограничение использования third-party скриптов на страницах redirect URI и про лимиты в защите, предоставляемой PKCE.
#article #security #oauth
👍5🤔1
401 Unauthorized: аутентификация и не только
ecom.teсh x keycloak community meetup 13 марта выступаю на митапе у ребят из ecom.tech, организованного совместно с русскоязычным keycloak-сообществом. Моя тема идет в самом начале и стартует сразу в 18:00. Поднимем вопрос о том, нужно ли использовать refresh…
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5👍4👏1
Identity Fabrics (часть 1)
Пришла тут на почту реклама European Identity and Cloud Conference 2025, решил посмотреть, какие доклады там на повестке и заметил, что внимание уделяется концепции Identity Fabrics.
Стало интересно попробовать разобраться, в чем же она заключается и есть ли в ней что-то новое, кроме красивых названий. Об этом, собственно, и поговорим.
Как первоисточник, вводящий такое понятие, нашел статью ещё 2020 года Leveraging Identity Fabrics on Your Way Towards Cloud Based IAM (полный материал за пейволлом выложить здесь не могу, однако доступ можно получить в рамках бесплатного trial-периода).
Тут нам говорится о том, что “традиционные IAM-решения не отвечают современным вызовам индустрии”, это и берется за проблематику.
Изначально определение вводится следующее:
Также пишут:
Составные части концепции показаны на изображении 1 (в порядке прикрепления к посту).
А дальше приводится ряд довольно пространных шагов (без негатива), которые и должны привести читателя к светлому будущему.
В общем, это некая вводная статья, которая по сути пока что “за все хорошее против всего плохого”.
Поэтому за конкретикой обратился к как раз недавно опубликованному уже более состоятельному материалу: The 2025 Identity Fabric and IAM Reference Architecture (модель доступа аналогичная).
В материал включены IAM Reference Architecture 2025, которая
И Identity Fabric 2025, который
А вместе они должны являться основой, затрагивающей полный спектр IAM-вопросов для построения комплексных систем.
Ключевые аспекты:
1️⃣ Building Block-Based Structure
2️⃣ Comprehensive Identity Coverage
3️⃣ Dynamic Authorization
4️⃣ Integrated Compliance
5️⃣ Support for Zero Trust
6️⃣ Strengthened Privileged Access Management
7️⃣ API and Interoperability Focus
8️⃣ Scalability Across Sectors
Далее разбирается сама концепция Identity Fabrics через освещение основных ее компонентов:
1️⃣ Human and Non-Human Identities
2️⃣ Target Systems
3️⃣ Core of the Identity Fabric: Capabilities, Services, and Tools
4️⃣ Integration of Legacy Systems
5️⃣ Support for Digital Services and API Connectivity
См. приложенное изображение 2.
Говорится о том, что Identity Fabric - это не только технический фреймворк, но и стратегическая движущая сила (enabler).
Интересна и связь с упомянутой IAM Reference Architecture. Пишут, что capabilities - и есть связующее звено между ними. Identity Fabric говорит о более верхнеуровневых вещах, в то время как IAM Reference Architecture предлагает уже более конкретные технические подходы и паттерны для каждой capability. Что должно помочь эффективной работе на разных уровнях и переходу от стратегических аспектов к архитектурным имплементациям.
В следующей части поговорим про любопытную идею Time Phases, а также саму IAM Reference Architecture.
#iam_general #article
Пришла тут на почту реклама European Identity and Cloud Conference 2025, решил посмотреть, какие доклады там на повестке и заметил, что внимание уделяется концепции Identity Fabrics.
Стало интересно попробовать разобраться, в чем же она заключается и есть ли в ней что-то новое, кроме красивых названий. Об этом, собственно, и поговорим.
Как первоисточник, вводящий такое понятие, нашел статью ещё 2020 года Leveraging Identity Fabrics on Your Way Towards Cloud Based IAM (полный материал за пейволлом выложить здесь не могу, однако доступ можно получить в рамках бесплатного trial-периода).
Тут нам говорится о том, что “традиционные IAM-решения не отвечают современным вызовам индустрии”, это и берется за проблематику.
Изначально определение вводится следующее:
Identity Fabrics are a concept that serves as a viable foundation for enterprise architectures for Identity and Access Management (IAM) that serve the business demand. They provide the capabilities required for supporting the business use cases, based on a well-defined set of services that are built in a modern architecture. These services aim at providing access for everyone (and everything) to every service and system, in a controlled manner. As such they can serve as the conceptual foundation for sustainably transforming existing IAM infrastructures into a future-proof basic technology.
Также пишут:
It serves as the logical architecture that unites different services and delivers the capabilities required by the enterprise.
Составные части концепции показаны на изображении 1 (в порядке прикрепления к посту).
А дальше приводится ряд довольно пространных шагов (без негатива), которые и должны привести читателя к светлому будущему.
В общем, это некая вводная статья, которая по сути пока что “за все хорошее против всего плохого”.
Поэтому за конкретикой обратился к как раз недавно опубликованному уже более состоятельному материалу: The 2025 Identity Fabric and IAM Reference Architecture (модель доступа аналогичная).
В материал включены IAM Reference Architecture 2025, которая
provides a detailed and modular framework for designing, evolving, and integrating IAM capabilities. It offers a clear separation of functional layers and capabilities to ensure consistency, adaptability, and scalability across organizations of varying industries and sizes
И Identity Fabric 2025, который
serves as a strategic framework for building flexible, service-oriented IAM ecosystems. Unlike traditional IAM frameworks, the Identity Fabric focuses on creating a cohesive service delivery model that integrates identity management capabilities into broader enterprise strategies.
А вместе они должны являться основой, затрагивающей полный спектр IAM-вопросов для построения комплексных систем.
Ключевые аспекты:
Далее разбирается сама концепция Identity Fabrics через освещение основных ее компонентов:
См. приложенное изображение 2.
Говорится о том, что Identity Fabric - это не только технический фреймворк, но и стратегическая движущая сила (enabler).
Интересна и связь с упомянутой IAM Reference Architecture. Пишут, что capabilities - и есть связующее звено между ними. Identity Fabric говорит о более верхнеуровневых вещах, в то время как IAM Reference Architecture предлагает уже более конкретные технические подходы и паттерны для каждой capability. Что должно помочь эффективной работе на разных уровнях и переходу от стратегических аспектов к архитектурным имплементациям.
В следующей части поговорим про любопытную идею Time Phases, а также саму IAM Reference Architecture.
#iam_general #article
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Identity Fabrics (часть 2)
Продолжаем обсуждение темы из предыдущего поста.
Понравилась концепция Time Phases. Здесь авторы говорят, что ранее выделяли только Deploy-Time (когда доступ и конфигурации identity определялись) и Run-Time (когда доступ применялся). Обновленная же модель вводит уже три различных фазы (с разбивкой одной из них):
1️⃣ Admin-Time
2️⃣ Real-Time (включает Session Initialization и Session Management)
3️⃣ Post-Event Time
Детальнее см. изображение 1 (в порядке прикрепления к посту). Зачем это нужно? Далее при рассмотрении capabilities для каждой из них будет указана и соответствующая time phase (или несколько их).
Подробно расписывается IAM Reference Architecture. Сама идея представлена в виде матрицы (см. изображение 2)
Выделяют 4 домена:
1️⃣ Administration
2️⃣ Analytics & Risk
3️⃣ Authentication
4️⃣ Authorization
5 функциональных уровней:
1️⃣ Core
2️⃣ Privileged
3️⃣ Extended
4️⃣ Integrations
5️⃣ API
И отдельный Foundation Layer, который поддерживает остальные и обеспечивает стабильность и функциональность IAM-инфраструктуры.
А затем идет уже детальный разбор каждой из capabilities - самая объемная часть. Прочесть ее оказалось интересно, особенно про те аспекты, с которыми не довелось сталкиваться. Единственно, жаль что про уровень API здесь написали мало.
И в конце указывается перечень рекомендаций для работы с данным фреймворками.
Подытожим. Identity Fabric есть концепция (парадигма) и одноименный фреймворк, который нацелен на выстраивание архитектуры (экосистемы) IAM на уровне предприятия (enterprise). Он предлагает не смотреть на отдельные компоненты как на изолированные части, а говорит, что они являются частью целого в современных IT-ландшафтах. Привносит ли он что-то принципиальное новое? Не сказал бы. Однако предлагаемый комплексный подход в том числе на уровне стратегии кажется интересным. Был бы я корпоративным архитектором, кто знает, может и попробовал бы взглянуть на архитектуру предприятия и подобным образом.
IAM Reference Architecture показалась достойной внимания. С одной стороны, если вы работали с функциями IAM в больших компаниях, многие поднимаемые вопросы будут вам уже знакомы. Но опять же общий взгляд может помочь избежать зашоренности взгляда порой.
Где это все может быть применимо? Тут мои мысли в целом совпадают с тем, что пишут сами авторы. Тобишь использоваться это может при проектировании новых архитектур, аудита и анализа существующих и подходов к снаряду для создания стратегии трансформации и модернизации. А еще подумал, что такая информация из IAM Reference Architecture может быть полезна и для формирования роадмапа к развитию: например, можно взять для более глубокой проработки интересующие capabilities.
#iam_general #article
Продолжаем обсуждение темы из предыдущего поста.
Понравилась концепция Time Phases. Здесь авторы говорят, что ранее выделяли только Deploy-Time (когда доступ и конфигурации identity определялись) и Run-Time (когда доступ применялся). Обновленная же модель вводит уже три различных фазы (с разбивкой одной из них):
Детальнее см. изображение 1 (в порядке прикрепления к посту). Зачем это нужно? Далее при рассмотрении capabilities для каждой из них будет указана и соответствующая time phase (или несколько их).
Подробно расписывается IAM Reference Architecture. Сама идея представлена в виде матрицы (см. изображение 2)
Выделяют 4 домена:
5 функциональных уровней:
И отдельный Foundation Layer, который поддерживает остальные и обеспечивает стабильность и функциональность IAM-инфраструктуры.
А затем идет уже детальный разбор каждой из capabilities - самая объемная часть. Прочесть ее оказалось интересно, особенно про те аспекты, с которыми не довелось сталкиваться. Единственно, жаль что про уровень API здесь написали мало.
И в конце указывается перечень рекомендаций для работы с данным фреймворками.
Подытожим. Identity Fabric есть концепция (парадигма) и одноименный фреймворк, который нацелен на выстраивание архитектуры (экосистемы) IAM на уровне предприятия (enterprise). Он предлагает не смотреть на отдельные компоненты как на изолированные части, а говорит, что они являются частью целого в современных IT-ландшафтах. Привносит ли он что-то принципиальное новое? Не сказал бы. Однако предлагаемый комплексный подход в том числе на уровне стратегии кажется интересным. Был бы я корпоративным архитектором, кто знает, может и попробовал бы взглянуть на архитектуру предприятия и подобным образом.
IAM Reference Architecture показалась достойной внимания. С одной стороны, если вы работали с функциями IAM в больших компаниях, многие поднимаемые вопросы будут вам уже знакомы. Но опять же общий взгляд может помочь избежать зашоренности взгляда порой.
Где это все может быть применимо? Тут мои мысли в целом совпадают с тем, что пишут сами авторы. Тобишь использоваться это может при проектировании новых архитектур, аудита и анализа существующих и подходов к снаряду для создания стратегии трансформации и модернизации. А еще подумал, что такая информация из IAM Reference Architecture может быть полезна и для формирования роадмапа к развитию: например, можно взять для более глубокой проработки интересующие capabilities.
#iam_general #article
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🔥1
Кстати, между делом похвастаюсь, что давеча появился в Зале Славы багбаунти Яндекса. К концу квартала нахожусь на почетном 27 месте в общем списке 💪
Про интересную обнаруженную уязвимость, связанную с тематикой канала, тоже напишу, но попозже.
Про интересную обнаруженную уязвимость, связанную с тематикой канала, тоже напишу, но попозже.
🔥9👏3👍1👎1
Видео The insecurity of OAuth 2.0 in frontends - Philippe de Ryck - NDC Security 2023
Еще одно выступление от Philippe De Ryck, про которого уже упоминал. Здесь автор уже говорит в целом про вопросы безопасности клиентских частей при использовании OAuth.
В докладе отмечается популяризация приложений, которые состоят только из одной клиентской части. Клиентская часть веб-приложений пишется на JavaScript, поэтому логично упоминаются возможности исполнения вредоносного JS в браузере, что может быть вызвано:
🔵 Скомпрометированной зависимостью или third-party скриптом
🔵 XSS
Справедливо упоминается никуда не уходящая популярность наличия XSS, с отсылкой на статистику HackerOne, где XSS по-прежнему на первом месте. В OWASP top 10 2021 3 пункт Injection также включает в себя XSS (кстати, полезно напомнить, что первым является Broken Access Control)
Автор обращает внимание, что при наличии токенов, доступных клиентской части в браузере, XSS несет дополнительный риск “извлечения токенов” (token exfiltration). Для снижения такого риска существующие практики рекомендуют меры вида снижения времени жизни токенов и ротации refresh-токенов вместе с защитой от переиспользования.
Далее автор говорит про недостаточность таких мер, если токены все еще доступны с клиентской части. Собственно об этом он писал еще давно в своих статьях.
Причину автор видит в недооцененности возможностей вредоносного JS, что довольно справедливо. Естественно, вредоносный JS выполняется в том же контексте и может все то же, что и легитимный код.
Говорится про фокус именно на краже существующих токенов, однако, фокусируясь только на этой проблеме, мы не замечаем слона в комнате. Атакующему совершенно не обязательно пытаться украсть существующие токены приложения. Еще один эффективный вектор атаки заключается в получении атакующим новых, других токенов. Полностью согласен с этим высказыванием, здорово, что такой вопрос стал подниматься чаще.
Приводится один из моих любимых примеров с т.н. “silent flow”, реализуемым через добавление iframe с URL authorization request с prompt=none и передачей authorization response родительскому окну через postMessage. Абсолютно логично, что в таком случае атакующий, имеющий возможность исполнения своего JS, может установить свой собственный EventListener на событие “message”, добавить невидимый пользователю iframe и, таким образом инициировав новый OAuth flow, похитить ответ, такой как authorization code с дальнейшим получением токенов на его основе. Еще раз хочу подчеркнуть, что пример абсолютно валидный. Детальнее про работу web message response mode тоже писал недавно, разбирая аутентификацию на портале разработчика Spotify.
Также приводится правильная мысль о том, что использование proof-of-possession, в частности DPoP, не поможет в таком случае. Атакующий средствами того же JS может прилинковать токены к своим DPoP-секретам.
Говорится о том, что люди стараются придумать различные меры защиты, не решающие root cause, в пример приводится использование service worker, имеющего возможность перехвата запросов. А затем автор демонстрирует недостатки такого подхода, заключающиеся в возможности дерегистрации service worker.
Однако далее это все подводится к тому, что мы не можем защитить OAuth-flow, используя только браузер, упоминается, что если атакующий имеет подконтрольный URL на том же самом origin приложения, такие варианты атак все еще возможны.
И в качестве решения здесь предлагается использование backend-компонента, который будет выполнять роль confidential client и реализовывать на себе всю работу с токенами. То что в контексте OAuth принято называть “Backend-for-Frontend (BFF)”. При этом на клиентскую часть возвращаются не сами токены, а некоторый session ID: то есть BFF создает отдельную сессию для пользователя.
(продолжение см. ниже)
#video #oauth
Еще одно выступление от Philippe De Ryck, про которого уже упоминал. Здесь автор уже говорит в целом про вопросы безопасности клиентских частей при использовании OAuth.
В докладе отмечается популяризация приложений, которые состоят только из одной клиентской части. Клиентская часть веб-приложений пишется на JavaScript, поэтому логично упоминаются возможности исполнения вредоносного JS в браузере, что может быть вызвано:
Справедливо упоминается никуда не уходящая популярность наличия XSS, с отсылкой на статистику HackerOne, где XSS по-прежнему на первом месте. В OWASP top 10 2021 3 пункт Injection также включает в себя XSS (кстати, полезно напомнить, что первым является Broken Access Control)
Автор обращает внимание, что при наличии токенов, доступных клиентской части в браузере, XSS несет дополнительный риск “извлечения токенов” (token exfiltration). Для снижения такого риска существующие практики рекомендуют меры вида снижения времени жизни токенов и ротации refresh-токенов вместе с защитой от переиспользования.
Далее автор говорит про недостаточность таких мер, если токены все еще доступны с клиентской части. Собственно об этом он писал еще давно в своих статьях.
Причину автор видит в недооцененности возможностей вредоносного JS, что довольно справедливо. Естественно, вредоносный JS выполняется в том же контексте и может все то же, что и легитимный код.
Говорится про фокус именно на краже существующих токенов, однако, фокусируясь только на этой проблеме, мы не замечаем слона в комнате. Атакующему совершенно не обязательно пытаться украсть существующие токены приложения. Еще один эффективный вектор атаки заключается в получении атакующим новых, других токенов. Полностью согласен с этим высказыванием, здорово, что такой вопрос стал подниматься чаще.
Приводится один из моих любимых примеров с т.н. “silent flow”, реализуемым через добавление iframe с URL authorization request с prompt=none и передачей authorization response родительскому окну через postMessage. Абсолютно логично, что в таком случае атакующий, имеющий возможность исполнения своего JS, может установить свой собственный EventListener на событие “message”, добавить невидимый пользователю iframe и, таким образом инициировав новый OAuth flow, похитить ответ, такой как authorization code с дальнейшим получением токенов на его основе. Еще раз хочу подчеркнуть, что пример абсолютно валидный. Детальнее про работу web message response mode тоже писал недавно, разбирая аутентификацию на портале разработчика Spotify.
Также приводится правильная мысль о том, что использование proof-of-possession, в частности DPoP, не поможет в таком случае. Атакующий средствами того же JS может прилинковать токены к своим DPoP-секретам.
Говорится о том, что люди стараются придумать различные меры защиты, не решающие root cause, в пример приводится использование service worker, имеющего возможность перехвата запросов. А затем автор демонстрирует недостатки такого подхода, заключающиеся в возможности дерегистрации service worker.
Однако далее это все подводится к тому, что мы не можем защитить OAuth-flow, используя только браузер, упоминается, что если атакующий имеет подконтрольный URL на том же самом origin приложения, такие варианты атак все еще возможны.
И в качестве решения здесь предлагается использование backend-компонента, который будет выполнять роль confidential client и реализовывать на себе всю работу с токенами. То что в контексте OAuth принято называть “Backend-for-Frontend (BFF)”. При этом на клиентскую часть возвращаются не сами токены, а некоторый session ID: то есть BFF создает отдельную сессию для пользователя.
(продолжение см. ниже)
#video #oauth
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1👏1🤔1
(продолжение предыдущего поста)
Здесь я совсем не разделяю оптимизм автора. Считаю, что не все так просто и красиво. В выступлении приводятся аргументы (1️⃣ ), на них напишу ответы (1️⃣ ).
1️⃣ : We can remove all OAuth 2.0 functionality from the frontend application
1️⃣ : Не могу себе представить, как это может быть верно. Мы добавили обычный бэкенд, теперь у нас реализация authorization code flow с серверной частью. Однако клиентская часть все еще участвует: authorization request выполняется из браузера, а не с бэкенда. Authorization response возвращается так же в браузер. Да, выполнение token request переезжает (и хорошо), но это не является всей функциональностью, на мой взгляд.
1️⃣ : Now we can reduce the attack surface from the full APIs that the token had access to to only the endpoints that the BFF exposes
1️⃣ : Проблема здесь в некорректном сравнении. Автор сравнивает вызов API через шлюз в виде BFF с прямым вызовом конечного сервиса. Но в реальных системах конечные сервисы и не выставляются наружу голой жопой напрямую. Перед ними обычно используются какие-либо варианты реализации паттерна API Gateway, ну или другие прокси. Да и сам access token скорее всего ограничивается как минимум набором scopes. Подход не приносит фактической разницы: эндпоинты, с которыми клиентская часть работает, все так же доступны, но теперь через компонент, называемый здесь “BFF”. И доступ к ним все так же возможен. В определенном смысле здесь нет разницы, что нужно подать на вход снаружи: сам access token или некую абстракцию над ним.
1️⃣ : The BFF observes all the API requests from a client, and can perform rate-limiting, anomaly detection, preventing data extraction and so on
1️⃣ : Изначальная проблема была совсем не в наличии прямого доступа к API, вот где вижу подмену понятий. С чем здесь сравнивается использование описанного подхода? С приложением, у которого есть только клиентская часть, нет своего бэкенда, а сервисы со всеми эндпоитнами выставлены “наружу” напрямую? Я не говорю, что такая реализация невозможна и такого не бывает, однако для нее в целом нет особого смысла говорить о “безопасности”, здесь by design ее не особо заложено. Для приложений, где НФТ к надежности и ИБ хоть сколько-то важны, подобного мы не увидим в любом случае. А здесь же снова мы пытаемся показать решение всех проблем добавлением дополнительного уровня абстракции. Confidential client в целом-то можно и по-другому реализовать, не обязательно добавлять именно BFF как проксирующий шлюз.
В итоге все подводится к тому, что подход с BFF значительно увеличивает безопасность. Только надо понять, в сравнении с чем. Автор поднял очень важные проблемы в первой части выступления, однако одно только добавление BFF как серверной части проксирующей запросы, не решает даже всего того скоупа упомянутых проблем. Делать токены доступными с клиентской части нехорошо, да. Но те же примеры с атакующим, способным инициировать новый OAuth flow, сами собой здесь не решатся.
Атакующему не особо нужно получать сам access token для доступа к API. Ему предложили новый интерфейс с дополнительной абстракцией - да ради бога. Атакующий может получить authorization code, передать его своему серверу, где уже выполнить запрос с передачей его самому приложению. При серверном вызове при этом ничто не мешает получить значение session ID в ответе: это будет всего лишь заголовок Set-Cookie, какие бы атрибуты мы у него не написали. Кстати, скоро планирую опубликовать материал как раз про подобные атаки. Так что, как говорится, stay tuned.
В заключении, описывая BFF как решение всех обозначенных проблем, автор добавляет, что:
Считаю утверждение довольно спорным. По крайней мере, есть и альтернативы, и все же подходы к “do better”.
Так точно ли BFF в данном случае - Best Friend Forever?
#video #oauth
Здесь я совсем не разделяю оптимизм автора. Считаю, что не все так просто и красиво. В выступлении приводятся аргументы (
В итоге все подводится к тому, что подход с BFF значительно увеличивает безопасность. Только надо понять, в сравнении с чем. Автор поднял очень важные проблемы в первой части выступления, однако одно только добавление BFF как серверной части проксирующей запросы, не решает даже всего того скоупа упомянутых проблем. Делать токены доступными с клиентской части нехорошо, да. Но те же примеры с атакующим, способным инициировать новый OAuth flow, сами собой здесь не решатся.
Атакующему не особо нужно получать сам access token для доступа к API. Ему предложили новый интерфейс с дополнительной абстракцией - да ради бога. Атакующий может получить authorization code, передать его своему серверу, где уже выполнить запрос с передачей его самому приложению. При серверном вызове при этом ничто не мешает получить значение session ID в ответе: это будет всего лишь заголовок Set-Cookie, какие бы атрибуты мы у него не написали. Кстати, скоро планирую опубликовать материал как раз про подобные атаки. Так что, как говорится, stay tuned.
В заключении, описывая BFF как решение всех обозначенных проблем, автор добавляет, что:
That’s as good as it gets. We can’t do better
Считаю утверждение довольно спорным. По крайней мере, есть и альтернативы, и все же подходы к “do better”.
Так точно ли BFF в данном случае - Best Friend Forever?
#video #oauth
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🤔1
Навигация по каналу ⛔️
Здесь описаны основные темы, освещаемые на канале, с использование хэштегов.
#iam_general — материалы про Identity & Access Management
#oauth — все, что касается OAuth и OIDC
#security — про безопасность
#api — проектирование, безопасность и интеграция API
#jwt — про JWT и работу с ними
#article — статьи из различных источников
#paper — полноформатные работы, научные статьи
#book — книги и обзоры книг
#video — обзоры видео-материалов, докладов, выступлений
#my_publication — мои опубликованные статьи
#my_talk — мои выступления, доклады
#announce — объявления о выступлениях, событиях
Для просмотра всех постов, относящихся к данной теме, можно использовать поиск по нужному хэштегу.
Список тегов будет дополняться по мере развития канала.
Здесь описаны основные темы, освещаемые на канале, с использование хэштегов.
#iam_general — материалы про Identity & Access Management
#oauth — все, что касается OAuth и OIDC
#security — про безопасность
#api — проектирование, безопасность и интеграция API
#jwt — про JWT и работу с ними
#article — статьи из различных источников
#paper — полноформатные работы, научные статьи
#book — книги и обзоры книг
#video — обзоры видео-материалов, докладов, выступлений
#my_publication — мои опубликованные статьи
#my_talk — мои выступления, доклады
#announce — объявления о выступлениях, событиях
Для просмотра всех постов, относящихся к данной теме, можно использовать поиск по нужному хэштегу.
Список тегов будет дополняться по мере развития канала.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🤔1
401 Unauthorized: аутентификация и не только pinned «Навигация по каналу ⛔️ Здесь описаны основные темы, освещаемые на канале, с использование хэштегов. #iam_general — материалы про Identity & Access Management #oauth — все, что касается OAuth и OIDC #security — про безопасность #api — проектирование, безопасность…»
Упрощение повторной аутентификации в PWA (часть 1)
Progressive Web Apps (PWA) - это веб-приложения, которые за счет использования дополнительных API позволяют улучшать UX и расширять функциональность стандартных возможностей веб-браузера. В случае мобильных платформ по сути такие PWA делаются выглядящими максимально приближенно к мобильным приложениям.
Я вообще давно с надеждой смотрю на использование PWA в применимых для них случаях. Например, для реализации тонких клиентов, где не нужны сложные вычисления или работа с графикой. Также PWA многим могут быть знакомы и в связи с другими обстоятельствами: в последние годы они стали в том числе актуальны и в банковской отрасли РФ в связи с удалением приложений ряда банков из сторов.
Долгое время их использование как полная альтернатива мобильным приложениям было под вопросом из-за особенностей политики Apple: Safari долгое время не поддерживал push-уведомления в PWA, что не давало разработчикам создавать полные аналоги "нативных" приложений и даже вынуждало городить разного рода костыли вроде отправки уведомлений в мессенджеры вместо этого для пользователей iOS.
Однако в 2023 году и Apple поддержала наконец возможность отправки пушей. Правда, потом убив PWA для жителей EU =(
С использованием PWA обычно хочется представить пользователю такой же опыт работы, как и в мобильном приложении. В том числе и в части аутентификации, ведь все знают, как пользователи это "любят".
В мобильных приложениях широко распространён подход с упрощением повторных входов для пользователя: обычно приложение получает долгоживущий refresh token, сохраняемый в защищенное хранилище ОС, который используется далее.
PWA такое повторить не могут. Нюанс в том, что PWA, при всем многообразии имеющихся API, доступа к защищённым хранилищам системы не имеют. Технически это все те же веб-приложения с теми же их особенностями и ограничениями.
Поэтому очень интересно подумать, а какие подходы сейчас используются, чтобы и при повторных входах не и не заставлять пользователя использовать все факторы аутентификации, и не делать, например, access token (в случае OAuth) совсем долгоживущим.
С одной стороны, раз это веб-приложения, то применяются известные практики для обновления access token, присущие им. Например:
1. Получение refresh token и хранение его в хранилищах клиентской части (таких как localStorage)
2. Получение refresh token и хранение его в HttpOnly-cookie (в том числе с другим path)
3. Обновление токенов через SSO
Однако, порой может быть важно в каком-то виде выполнить и подтверждение identity пользователя на момент входа - вроде того, что в WebAuthn называют User Verification.
Поэтому есть и принципиально другие подходы. В них при повторном входе мы все равно каждый раз выполняем аутентификацию пользователя, но уже по другой, альтернативной цепочке. Как правило, такая цепочка будет включать уже другие специфичные факторы, использование которых должно быть "проще" для пользователя.
Здесь можно выделить отдельный PIN-код для устройства и использование passkeys (через WebAuthn)
В следующей части посмотрим на такие подходы чуть подробнее уже на конкретном примере.
#iam_general
Progressive Web Apps (PWA) - это веб-приложения, которые за счет использования дополнительных API позволяют улучшать UX и расширять функциональность стандартных возможностей веб-браузера. В случае мобильных платформ по сути такие PWA делаются выглядящими максимально приближенно к мобильным приложениям.
Я вообще давно с надеждой смотрю на использование PWA в применимых для них случаях. Например, для реализации тонких клиентов, где не нужны сложные вычисления или работа с графикой. Также PWA многим могут быть знакомы и в связи с другими обстоятельствами: в последние годы они стали в том числе актуальны и в банковской отрасли РФ в связи с удалением приложений ряда банков из сторов.
Долгое время их использование как полная альтернатива мобильным приложениям было под вопросом из-за особенностей политики Apple: Safari долгое время не поддерживал push-уведомления в PWA, что не давало разработчикам создавать полные аналоги "нативных" приложений и даже вынуждало городить разного рода костыли вроде отправки уведомлений в мессенджеры вместо этого для пользователей iOS.
Однако в 2023 году и Apple поддержала наконец возможность отправки пушей. Правда, потом убив PWA для жителей EU =(
С использованием PWA обычно хочется представить пользователю такой же опыт работы, как и в мобильном приложении. В том числе и в части аутентификации, ведь все знают, как пользователи это "любят".
В мобильных приложениях широко распространён подход с упрощением повторных входов для пользователя: обычно приложение получает долгоживущий refresh token, сохраняемый в защищенное хранилище ОС, который используется далее.
PWA такое повторить не могут. Нюанс в том, что PWA, при всем многообразии имеющихся API, доступа к защищённым хранилищам системы не имеют. Технически это все те же веб-приложения с теми же их особенностями и ограничениями.
Поэтому очень интересно подумать, а какие подходы сейчас используются, чтобы и при повторных входах не и не заставлять пользователя использовать все факторы аутентификации, и не делать, например, access token (в случае OAuth) совсем долгоживущим.
С одной стороны, раз это веб-приложения, то применяются известные практики для обновления access token, присущие им. Например:
1. Получение refresh token и хранение его в хранилищах клиентской части (таких как localStorage)
2. Получение refresh token и хранение его в HttpOnly-cookie (в том числе с другим path)
3. Обновление токенов через SSO
Однако, порой может быть важно в каком-то виде выполнить и подтверждение identity пользователя на момент входа - вроде того, что в WebAuthn называют User Verification.
Поэтому есть и принципиально другие подходы. В них при повторном входе мы все равно каждый раз выполняем аутентификацию пользователя, но уже по другой, альтернативной цепочке. Как правило, такая цепочка будет включать уже другие специфичные факторы, использование которых должно быть "проще" для пользователя.
Здесь можно выделить отдельный PIN-код для устройства и использование passkeys (через WebAuthn)
В следующей части посмотрим на такие подходы чуть подробнее уже на конкретном примере.
#iam_general
👍4🤔1
Опубликовал результаты исследования любопытного вектора атаки в виде статьи:
https://habr.com/ru/articles/880544/
В ней узнаем, что такое «прерывание OAuth flow» и как его применять, затронем использование паттерна Backend‑for‑Frontend и способы реализации PKCE для confidential clients, попутно проверив, помогают ли они защититься от рассматриваемой атаки. Взглянем и на другие существующие рекомендации и предлагаемые лучшие практики, а также подумаем над прочими мерами защиты, которые действительно могут помочь. Все это с примерами, схемами и даже видео.
Также есть версия на английском языке на Medium (и на dev.to).
#my_publication #oauth #security
https://habr.com/ru/articles/880544/
В ней узнаем, что такое «прерывание OAuth flow» и как его применять, затронем использование паттерна Backend‑for‑Frontend и способы реализации PKCE для confidential clients, попутно проверив, помогают ли они защититься от рассматриваемой атаки. Взглянем и на другие существующие рекомендации и предлагаемые лучшие практики, а также подумаем над прочими мерами защиты, которые действительно могут помочь. Все это с примерами, схемами и даже видео.
Также есть версия на английском языке на Medium (и на dev.to).
#my_publication #oauth #security
🔥8🤔2
Как говорил профессор Фарнсворт из Футурамы: "Good news, everyone!"
📆 Уже 23 мая буду выступать на PHDays в Москве с докладом "Токены доступа и API Gateway: как обеспечить безопасность запросов" — [ссылка на доклад]
(ребята из оргкомитета PHDays прислали и вот такую "красивую блогерскую картинку" (дословно!), так что ее тоже прикрепляем к посту)
📆 А всего через неделю после, 31 мая, я перемещаюсь в Новосибирск, где также выступлю с данной темой на🎙 CodeFest 15 — [ссылка на доклад]
В докладе поговорим про различные подходы использования API Gateway как части более общего API security-решения в контексте его работы с токенами доступа и подумаем, а есть ли лучший из них. Также обсудим, почему нужно ограничивать область действия access token и может ли API Gateway помочь и в данном вопросе.
Так что, кто уже спланировал посетить данные конференции, приходите на доклад и просто пообщаться-познакомиться. А кто пока только планирует, вот вам еще один повод😊
#announce #my_talk #api #iam_general
📆 Уже 23 мая буду выступать на PHDays в Москве с докладом "Токены доступа и API Gateway: как обеспечить безопасность запросов" — [ссылка на доклад]
(ребята из оргкомитета PHDays прислали и вот такую "красивую блогерскую картинку" (дословно!), так что ее тоже прикрепляем к посту)
📆 А всего через неделю после, 31 мая, я перемещаюсь в Новосибирск, где также выступлю с данной темой на
В докладе поговорим про различные подходы использования API Gateway как части более общего API security-решения в контексте его работы с токенами доступа и подумаем, а есть ли лучший из них. Также обсудим, почему нужно ограничивать область действия access token и может ли API Gateway помочь и в данном вопросе.
Так что, кто уже спланировал посетить данные конференции, приходите на доклад и просто пообщаться-познакомиться. А кто пока только планирует, вот вам еще один повод
#announce #my_talk #api #iam_general
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥3🤔2
Упрощение повторной аутентификации в PWA (часть 2)
Предыдущий пост закончили на применении отдельного PIN и passkeys. Попробуем наглядно это рассмотреть, взяв для примера Сбербанк Онлайн. Клиентская часть Сбербанк Онлайн как раз выполнена в виде PWA, вот их манифест.
Собственно, после первичной аутентификации пользователя Сбербанк Онлайн предлагает создать код (PIN) для данного устройства, с помощью которого можно будет выполнять аутентификацию далее.
———
🖼 Скриншоты в посте добавлены в порядке упоминания в тексте.
———
➡️ При аутентификации с помощью кода отправляется запрос /pin/begin (скриншот 1).
➡️ За ним следует запрос /pin/logon (скриншот 2).
➡️ И затем уже выполняется запрос к /app/auth, в результате которого серверная часть устанавливает нам нужные куки.
Но что это за “srp_” параметры и где наш PIN в запросах? Судя по всему, Сбербанк Онлайн использует Secure Remote Password protocol (SRP). Протокол реализует доказательство с нулевым разрешением (zero-knowledge proof), при котором сам PIN вообще не передается по каналу связи. На эту тему есть несложная статья на хабре, которая при этом наглядно объясняет принцип работы протокола. В ней, кстати, мы как раз можем увидеть, зачем нужны передаваемые в примерах параметры.
Также Сбербанк Онлайн предлагает создать и passkey, чтобы использовать уже его при дальнейших входах при помощи WebAuthn.
➡️ Тогда, естественно, никакого SRP уже нет, а есть запрос из authentication ceremony (скриншот 3).
➡️ Далее опять же после запроса к /app/auth устанавливаются необходимые куки.
Что здесь примечательно? Как видно из описанного процесса, данная последовательность запросов не то чтобы особо напоминает какой-либо OAuth flow. Соответственно, вполне логично, что подобный подход можно использовать и вне OAuth/OIDC.
Кстати, в ходе экспериментов выявлено, что при использовании PWA с десктопа Сбербанк Онлайн, помимо passkey, запрашивал каждый раз еще и OTP из SMS, чего не происходило при тестировании с мобильного устройства. Детально разбираться уже не стал, подозреваю, что влияет передаваемый отпечаток (fingerprint).
При использовании passkeys есть и нюанс. WebAuthn не позволяет ограничить, какой именно метод для user verification должен быть использован: это нельзя указать при начале церемонии, нельзя подобные данные получить и в authenticator data. Соответственно, со стороны приложения (relying party, RP в терминах WebAuthn) мы не сможем отличить, использовал ли пользователь для подтверждения своей identity на устройстве биометрию (например, отпечаток или распознавание лица) или же просто ввел системный PIN для разблокировки устройства (который у кого-то может быть выведен во что-то вроде “0000”). Если интересно почитать про user verification и user presence в WebAuthn, мне понравилась статья WebAuthn User Verification & User Presence for Passkeys.
Вообще сама спецификация предусматривает ряд расширений (extensions). Так существует и
User Verification Method Extension (uvm), которое как раз должно позволять RP получать значение использованного пользователем verification method. Например, здесь явно зарегистрированы такие значения как
Не менее интересно и обоснование, почему это не поддерживается, взятое по ссылке выше:
#iam_general
Предыдущий пост закончили на применении отдельного PIN и passkeys. Попробуем наглядно это рассмотреть, взяв для примера Сбербанк Онлайн. Клиентская часть Сбербанк Онлайн как раз выполнена в виде PWA, вот их манифест.
Собственно, после первичной аутентификации пользователя Сбербанк Онлайн предлагает создать код (PIN) для данного устройства, с помощью которого можно будет выполнять аутентификацию далее.
———
🖼 Скриншоты в посте добавлены в порядке упоминания в тексте.
———
Но что это за “srp_” параметры и где наш PIN в запросах? Судя по всему, Сбербанк Онлайн использует Secure Remote Password protocol (SRP). Протокол реализует доказательство с нулевым разрешением (zero-knowledge proof), при котором сам PIN вообще не передается по каналу связи. На эту тему есть несложная статья на хабре, которая при этом наглядно объясняет принцип работы протокола. В ней, кстати, мы как раз можем увидеть, зачем нужны передаваемые в примерах параметры.
Также Сбербанк Онлайн предлагает создать и passkey, чтобы использовать уже его при дальнейших входах при помощи WebAuthn.
Что здесь примечательно? Как видно из описанного процесса, данная последовательность запросов не то чтобы особо напоминает какой-либо OAuth flow. Соответственно, вполне логично, что подобный подход можно использовать и вне OAuth/OIDC.
Кстати, в ходе экспериментов выявлено, что при использовании PWA с десктопа Сбербанк Онлайн, помимо passkey, запрашивал каждый раз еще и OTP из SMS, чего не происходило при тестировании с мобильного устройства. Детально разбираться уже не стал, подозреваю, что влияет передаваемый отпечаток (fingerprint).
При использовании passkeys есть и нюанс. WebAuthn не позволяет ограничить, какой именно метод для user verification должен быть использован: это нельзя указать при начале церемонии, нельзя подобные данные получить и в authenticator data. Соответственно, со стороны приложения (relying party, RP в терминах WebAuthn) мы не сможем отличить, использовал ли пользователь для подтверждения своей identity на устройстве биометрию (например, отпечаток или распознавание лица) или же просто ввел системный PIN для разблокировки устройства (который у кого-то может быть выведен во что-то вроде “0000”). Если интересно почитать про user verification и user presence в WebAuthn, мне понравилась статья WebAuthn User Verification & User Presence for Passkeys.
Вообще сама спецификация предусматривает ряд расширений (extensions). Так существует и
User Verification Method Extension (uvm), которое как раз должно позволять RP получать значение использованного пользователем verification method. Например, здесь явно зарегистрированы такие значения как
USER_VERIFY_FINGERPRINT или USER_VERIFY_PASSCODE. Однако, к сожалению, в Chrome такое не работает =(Не менее интересно и обоснование, почему это не поддерживается, взятое по ссылке выше:
Experiences such as "this website only works with my left index finger" and "I can't log into this website while wearing a mask" are not things that we wish to support. They damage the experience, and thus reputation, of modern authentication in general and encourage people to stick with passwords.
#iam_general
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🤔1