Кстати про уязвимую проверку 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

Тем временем моя статья "Атаки через новый OAuth flow, authorization code injection, и помогут ли HttpOnly, PKCE и BFF" стала победителем в ежегодном конкурсе статей на Хабре Технотекст 7 в номинации "Информационная безопасность" 🥳


Все итоги конкурса: https://habr.com/ru/companies/habr/articles/911650/

Также прикладываю презентацию с выступления.

Книга "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

[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.

Третья часть обзора книги “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

Как “превратить” 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, используя именно 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 token
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

Гора родила мышь, а я наконец родил статью на основе материала, про который рассказывал весной на PHDays 2025 и CodeFest 15.

https://habr.com/ru/articles/872918/

#api #oauth #my_publication

SSO из мобильного приложения в web

Я однажды уже писал про подходы к реализации SSO в мобильных приложениях. Кстати, там была упомянута спецификация OpenID Connect Native SSO for Mobile Apps , и с тех пор Authlete опубликовали классное описание, как ее у себя реализовали, можно почитать.

В том посте я фокусировался на возможности аутентификации в самих мобильных приложения, в том числе с использованием сессии в браузере. Однако бывают и обратные примеры: когда пользователь уже аутентифицирован в мобильном приложении, и его нужно отправить на некоторый ресурс в браузере, причем "волшебным образом" обеспечив и там аутентифицированное состояние. И задача логично усложняется в ситуации, когда в этот момент у пользователя может не быть cookie с активной SSO-сессией. Касается это и случаев, когда в качестве экземпляров браузера используют WebView и его аналоги для iOS.
Вот про подходы к решению такой задачи сегодня и поговорим.

Недавно я заметил в документации Roox UIDM описание любопытной функциональности: бесшовный переход из мобильных приложений в Web, и стало интересно разобраться подробнее.

Подход основан на кастомном grant type urn:roox:params:oauth:grant-type:m2m-authorization-code. В нем получаемый в мобильном приложении (МП) access token обменивается сразу на authorization code для веб-приложения. Далее МП передает полученный authorization code на адрес redirect URI веб-приложения, после чего веб-приложение штатным способом уже выполняет получение токенов.

Однако подход пока смущает, мне не до конца понятно, почему он такой и как работает.
1. Почему выполняется обмен именно access token и именно на authorization code? Как можно превратить "делегированный доступ в рамках X для client A" в "авторизацию доступа в рамках Y для client B"?
2. Как быть с самим механизмом делегирования доступа? В рамках какой области действия (те же scopes) он делегируется при создании authorization code? Как быть, если пользователь не давал согласия (consent) веб-приложению? Здесь authorization server выдает authorization code как подтверждение того, что "пользователь разрешил веб-приложению доступ к своим данным в рамках Y", хотя пользователя вообще не спрашивали, ну и подозреваю, что совсем не обязательно scopes веб-приложения могут входить в scopes МП
3. Как и чем обеспечивается возможность конкретно для client A получить от authorization server authorization code конкретно для client B, что мешает ему получить authorization code для любого другого клиента? Здесь уверен, у ребят какая-то настройка предусмотрена, но вот не написали, какая(

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

Так, например, в Curity некогда придумали подход Nonce Authenticator Pattern. Здесь предлагают получать специальное одноразовое значение - nonce - на основе ID token. Затем это значение передаётся веб-приложению, которое использует его как один из параметров authorization request.

Свой подход есть и у Auth0 (Okta), назвали его Native to Web SSO. Выглядит интереснее: используется обмен refresh token на специальный session transfer token. Он передаётся веб-приложению и служит для создания SSO-сессии в браузере, причем он является одноразовым, короткоживущим, и его можно привязать, например, к IP (в рекламе обещают device binding, но врут: только к IP и ASN). После создания SSO-сессии веб-приложение уже может выполнить стандартный authorization request и продолжить OAuth flow в обычном режиме.

У меня здесь пока нет готового ответа, как бы сделал я. Но считаю, что переносить нужно "identity для ограниченного SSO", поэтому создание SSO-сессии в браузере кажется логичным, и направление мысли скорее в сторону подхода Auth0/Okta.

#oauth #iam_general

Про form post response mode

В начале 2025 года я провел, а весной опубликовал результаты исследования в виде статьи “Атаки через новый OAuth flow, authorization code injection, и помогут ли HttpOnly, PKCE и BFF”, где также описывал и меры для защиты от рассматриваемых сценариев атак.

Самым интересным для меня оказался вывод, показывающий фундаментальную проблему: authorization code grant в OAuth закладывает разбиение процесса авторизации на отрезки, при этом позволяя выполнить отдельный участок процесса вообще вне сеанса пользователя, чем нивелируется наличие любых защитных механизмов браузера. Отсюда и идет сложность с выбором защитных мер.
В статье я пришел к выводу, что единственной полноценной мерой защиты является использование form post response mode, поскольку он не делает authorization response доступным с origin самого приложения, а передает его сразу серверной части в POST-запросе. Про него, а также другие response modes писал здесь.

Шло время, а я продолжал думать: почему form post response mode не является особо популярным. Не только он не получил широкого распространения, но и рекомендаций к его использованию вместо того же де-факто “стандартного ” query response mode мы нигде не находим. Стал размышлять в сторону сравнения query и form post response modes: а не стоит ли для большинства случаев по умолчанию считать form post более безопасным и подходящим и сразу использовать его, оставляя query для тех сценариев, где он действительно оправдан? Ну или хотя бы отмечать его применимость, чтобы он перестал быть “маргинальным”.

И вот в октябре решил посоветоваться по этому вопросу в переписке рабочей группы OAuth. Коли form post хорош, чего же нигде не пишем про такие возможности? Упустили или есть какие-то еще причины, которых не увидел? Собственно, в течение пары недель была дискуссия, в том числе затрагивающая и потенциальные недостатки.

При этом в начале ноября на очередном митинге рабочей группы товарищ Jonas Primbs поднял вопрос актуальности Browser Swapping attacks и мер защиты от них (в общем-то тех же самых). Как я отмечал в статье, это название такого же сценария атаки, просто зачем-то суженное именно до браузера атакующего (который вообще можно не использовать). Также завели PR в OAuth 2.1

После этого параллельно стартовала соседняя дискуссия - про Browser Swapping. По контексту они часто перекликались. Интересным там оказалось недавнее письмо от товарища из MS Entra, написанное уже под конец года, после основных обсуждений.

Он подсветил интересную свежую фишинговую атаку как раз на MS Entra: ConsentFix. Авторы отмечают, что данную атаку можно рассмотреть как продолжение известной ClickFix, про которую многие писали в этом году, однако здесь она происходит полностью в браузере.

В двух словах суть следующая: как и в ClickFix-атаке, пользователь видит фейковое окошко вида “подтвердите, что вы не робот”, которое может появиться и на легитимных сайтах ввиду наличия уязвимостей на них самих. Далее после нехитрых манипуляций выполняется переадресация браузера пользователя на URL authorization request в MS Entra, где в качестве значения client_id используется идентификатор Azure CLI. При наличии SSO-сессии пользователя успешно редиректит с authorization code в URL на localhost, однако на нем у него, естественно, ничего не поднято. И поэтому его просят “скопировать значение из адресной строки, чтобы подтвердить доступ”.

А суть его письма в том, что, кроме обсуждаемых сценариев для веб-приложений, есть еще и релевантные кейсы для нативных клиентов, в которых form post тоже мог бы повысить безопасность.

Еще одним итогом можно считать идею от Dick Hardt по добавлению в браузеры нового механизма для поддержки особых заголовков, которые можно использовать для передачи authorization response без раскрытия его клиентской части, которая родилась после дискуссий выше. Идея пока сырая, но все же.

Что имеем в остатке? Внимание к проблеме начало появляться, она начинает осознаваться, а это уже хорошо.

#oauth