FAPI 2.0 или базовый OAuth: какой профиль безопасности на самом деле указан в запросе банковского API?
Сравните утверждение протокола, свойство безопасности и свидетельства соответствия, прежде чем проверять запрос банковского API, в котором указано только OAuth или FAPI 2.0.
Сигналы для наблюдения
- Проверяющая сторона называет точный профиль FAPI или OAuth и роль развертывания, а не говорит только о совместимости с OAuth.
- Сервер авторизации и клиент согласовывают PAR, PKCE и метод токена с ограничением отправителя.
- Результат соответствия или тест на уровне конечной точки привязан к среде выпуска и владельцу.
«Соответствует OAuth» и «Требуется FAPI 2.0» — не два взаимозаменяемых ярлыка для одного банковского API. OAuth 2.0 задаёт основу авторизации; профиль безопасности FAPI 2.0 сужает и ужесточает выбор механизмов OAuth для критичных API, включая передаваемые запросы авторизации (PAR) с аутентификацией клиента, PKCE и токены доступа с ограничением по отправителю. В проекте нужно указать точный профиль и доказательства, а не просто показать, что конечная точка токена отвечает.
Это различие важно инженеру по продажам решений идентификации для финансовых API, который просматривает разрешённые Telegram-группы открытого банкинга, банковских разработчиков и специалистов по идентификации. Ответ с опозданием на день может пропустить слот тестирования соответствия или выпуск интеграции. Коммерческое предложение, основанное лишь на слове «OAuth», может не учесть изменения сервера авторизации, клиента и сервера ресурсов, которых ожидает доверяющая сторона.
Вот иллюстративный составной диалог, а не банковский запрос или результат теста:
“Вход в песочницу работает с OAuth. Партнер говорит, что рабочая среда должна быть FAPI 2.0. Нам просто изменить области?”
В обмене не учитываются роль API, сервер авторизации, тип клиента, версия профиля, текущий поток, аутентификация клиента, метод привязки токена, пакет соответствия, неудачный тест и владелец производства.
Сравнивается структура и ограниченный профиль, а не старый и новый брендинг.
RFC 6749 определяет роли OAuth 2.0 и права авторизации. Он намеренно оставляет множество вариантов развертывания. Слова «мы используем OAuth» могут описать легитимный поток кода авторизации без определения свойств безопасности, необходимых для ценной экосистемы.
Профиль безопасности OpenID Foundation FAPI 2.0 основан на OAuth и связанных с ним стандартах. В его введении говорится, что он охватывает клиентов, получающих токены с ограниченным отправителем и использующих их с серверами ресурсов, и что он был разработан для ценных интерфейсов прикладного программирования (API). Банк или открытая банковская экосистема могут добавлять дополнительные правила; «FAPI 2.0» по-прежнему требует точного документа, версии и локального профиля.
| Вопрос о доказательствах | Базовое утверждение OAuth может установить | Профиль безопасности FAPI 2.0 ожидает |
|---|---|---|
| Запрос авторизации | Поддерживаемый поток авторизации OAuth | Поток кода авторизации с передаваемыми запросами авторизации (PAR), аутентифицированными клиентом |
| Защита от перехвата кода | Выбор OAuth в зависимости от развертывания | Ключ подтверждения для обмена кодами (PKCE) с методом запроса S256 |
| Кража токена доступа | Могут использоваться токены на предъявителя | Токены с ограничением по отправителю с использованием взаимного TLS или доказательства владения (DPoP) |
| Аутентификация клиента | Зависит от клиента и развертывания | Конфиденциальные клиенты и определенные варианты аутентификации |
| Доказательство | Успешный тест конечной точки или интеграции | Поведение, специфичное для профиля, плюс необходимые доказательства соответствия экосистемы |
| В таблице не указано, что базовый уровень OAuth является «небезопасным». В нем говорится, что общее утверждение OAuth не может соответствовать более узкому профилю. |
Доказательства профиля также зависят от роли. Клиентский тест не может установить полное поведение сервера авторизации, а трассировка сервера авторизации не может доказать, что сервер ресурсов отклоняет украденный токен, не имеющий необходимого ключа или сертификата. Записывайте клиента, сервер авторизации и сервер ресурсов отдельно, даже если один поставщик выполняет более одной роли.
Проведите один запрос авторизации через четыре контрольные точки
Самый короткий полезный тест на пробелы следует за одним запросом, а не за сравнением списков функций продукта.
Контрольная точка 1: передача запроса
Сервер авторизации FAPI 2.0 должен поддерживать передаваемые запросы авторизации по RFC 9126 с аутентификацией клиента и отклонять запросы авторизации, переданные без PAR. Клиент отправляет параметры авторизации по аутентифицированному обратному каналу, а затем использует возвращённый request_uri в конечной точке авторизации.
Контрольная точка 2: код авторизации
Для профиля требуется PKCE с S256. Он также устанавливает максимальное время жизни кода авторизации 60 секунд. Перенаправление в песочницу, возвращающее код, не показывает, что какое-либо правило было применено.
Контрольная точка 3: клиент и токен доступа
Сервер авторизации выдает только токены доступа с ограничением отправителя и использует либо взаимную безопасность транспортного уровня в соответствии с RFC 8705, либо DPoP согласно RFC 9449. Аутентификация клиента и привязка токена — это разные вопросы: например, в профиле указан взаимный TLS или private_key_jwt для аутентификации клиента, тогда как ограничение отправителя токена использует взаимный TLS или DPoP.
Контрольная точка 4: запрос ресурсов и доказательства
Сервер ресурсов должен проверить токен и его ограничение отправителя с помощью выбранного метода. Затем команде нужен объект доказательства, который принимает партнер: результат набора соответствия, трассировка конечной точки, запись сертификации или тест, специфичный для экосистемы. Не называйте местный дымовой тест сертификацией.
Рабочий процесс резервного входа при сбое passkey (English) относится к восстановлению аутентификации, а не к авторизации API. Статья о доказательствах при проверке SOC 2 показывает, как привязать запрос подтверждения к конкретной принимаемой записи.
Определите объём миграции по первой неудачной контрольной точке
Если PAR отсутствует, проект может потребовать изменения метаданных сервера авторизации, конечной точки PAR, аутентификации клиента и изменения запроса клиента. Если PKCE присутствует, но токены доступа предназначены только для носителя, основная работа может заключаться в жизненном цикле ключа или сертификата и проверке сервера ресурсов. Если все поведение во время выполнения соответствует требованиям, но партнер отвергает доказательства, проект может представлять собой тестирование и пакетирование соответствия, а не перепроектирование протокола.
TOP Prospect может объединять неполные фрагменты из групп Telegram, которые пользователь намеренно подключает и имеет к ним доступ, сохранять исходный текст, источник и время, удалять очевидные дубликаты и ранжировать кандидата для проверки человеком. Он не может проверять конечные точки, хранить ключи клиентов, запускать пакет соответствия банка, сертифицировать FAPI или выбирать профиль экосистемы. Страница тарифов описывает границу обнаружения. Руководство по поиску клиентов для платёжных решений рассматривает коммерческий спрос, а не протокольные доказательства.
Вернитесь к диалогу о тестовой среде. «Изменить области действия» возможно только после того, как контрольные точки запроса, кода, токена и сервера ресурсов уже соответствуют указанному производственному профилю. В случае неудачи определите область действия этого объекта и его владельца. Полезное сравнение – это не OAuth и FAPI как конкурирующие продукты; это текущее свидетельство конечной точки в сравнении со свойствами безопасности, которые фактически требуются проверяющей стороне.
Часто задаваемые вопросы
Является ли FAPI 2.0 заменой OAuth 2.0?
Нет. Он основан на OAuth 2.0 и связанных с ним стандартах, но при этом сужает выбор и добавляет требования к дорогостоящим API.
Подтверждает ли токен доступа OAuth соответствие FAPI 2.0?
Нет. Это не подтверждает PAR, PKCE с S256, токены с ограничением отправителя, проверку эмитента или другое поведение профиля.
Должен ли FAPI 2.0 использовать взаимный TLS, а не DPoP?
Нет. Профиль допускает ограничение отправителя с помощью взаимного TLS или DPoP при соблюдении его подробных требований.
Что делает запрос готовым к предложению по реализации?
Назовите роли, версию профиля, метод ограничения отправителей, доказательства, среду, неудачный тест и владельца выпуска.
Часто задаваемые вопросы
Является ли FAPI 2.0 заменой OAuth 2.0?
Нет. Профиль безопасности FAPI 2.0 основан на OAuth 2.0 и связанных с ним стандартах, что сужает выбор и добавляет требования для сценариев API с высокой ценностью.
Подтверждает ли токен доступа OAuth соответствие FAPI 2.0?
Нет. Успешный ответ с токеном не подтверждает передаваемые запросы авторизации (PAR) с аутентификацией клиента, PKCE с S256, токены с ограничением по отправителю, проверку эмитента или остальные требования выбранного профиля.
Должен ли FAPI 2.0 использовать взаимный TLS, а не DPoP?
Нет. Профиль безопасности разрешает токены доступа с ограничением отправителя с использованием взаимного TLS в соответствии с RFC 8705 или демонстрации доказательства владения в соответствии с RFC 9449, с учетом конкретных требований к серверу и клиенту.
Что делает запрос готовым к предложению по реализации?
Назовите роль API, сервер авторизации, тип клиента, точный профиль и версию, метод ограничения отправителей, необходимые доказательства соответствия, среду, неудачный тест и подотчетного владельца выпуска.
Источники и дополнительное чтение
Как обнаруживается Signal, заслуживающий внимания
Методика показывает, как Top Prospect находит и упорядочивает Signals, которые стоит проверить, сохраняет исходный контекст Telegram, удаляет дубли и помогает определить порядок просмотра. Решение о дальнейших действиях остаётся за вами.
