Ресурсы · 43
OAuth и OpenID Connect: проверка интеграции от начала до конца
Разделение прав доступа при входе в систему, делегировании и передаче данных, затем тестирование перенаправлений, токенов, сессий и отзыва.
Обновлено · 3 min
Чего помогает достичь это руководство
- Разделение идентификации и авторизации.
- Отклонение непреднамеренных перенаправлений и токенов.
- Тщательное тестирование отказов и успешных действий.
- Проверка удаления доступа после ухода или инцидента.
Быстрая проверка
- Какой поставщик и эмитент ожидаются?
- Точно ли зарегистрирован URI перенаправления?
- Не используется ли токен идентификации ошибочно в качестве токена доступа?
- Проверяет ли каждый ресурс право собственности?
- Какой доступ сохраняется после отзыва?
Пошаговый метод
- 1
Схема развернутого потока.
Идентификация публичного или конфиденциального клиента, браузера, сервера авторизации, API и поставщика OIDC. Зафиксируйте, куда перемещаются коды и токены, кто их хранит и какие роли предоставлены. Схема продаж не отражает фактическое развертывание.
Результат: поток, границы доверия и владельцы компонентов.
- 2
Проверка транзакции входа в систему.
Используйте поток кода с PKCE, соответствующим клиенту. Проверьте S256, привязку транзакций, зарегистрированные перенаправления и защиту от поддельных запросов. Протестируйте неожиданный URI, некорректный верификатор, воспроизведенный код и неожиданного эмитента. RFC 9700 разделяет требования и рекомендации по типу клиента.
Результат: разрешенные и запрещенные результаты тестирования.
- 3
Проверка правильности токена.
API проверяет свой токен доступа в соответствии с форматом и правилами поставщика: подпись или интроспекция, эмитент, аудитория, срок действия и разрешения. Клиент OIDC отдельно проверяет токен идентификации. Действительная подпись не подтверждает принадлежность токена этому API.
Результат: проверка контракта, аудитории и тестов на истечение срока действия.
- 4
Проверка прав доступа.
Тестирование объекта, принадлежащего другой учетной записи, роли более низкого уровня, закрытого поля и административной операции. Область действия или аутентифицированный шлюз не заменяют серверные проверки запрашиваемого ресурса. Используйте авторизованные тестовые учетные записи и данные.
Результат: матрица ролей, объектов, операций и ожидаемых отказов.
- 5
Проверка истечения срока действия и отзыва.
Разделение локальной сессии, сессии поставщика, токена доступа и токена обновления. Тестирование выхода из системы, потери устройства, изменения роли, ротации ключа подписи и сбоя поставщика. Документирование остаточного времени доступа вместо предположения, что выход из системы немедленно отзывает все.
Результат: временная шкала удаления доступа и исключения.
- 6
Наблюдение без раскрытия секретов.
Журналирование ссылки на транзакцию, решения о проверке, категории ошибки и версии конфигурации. Исключить коды, токены и секреты. Подготовить диагностику, завершить интеграцию и откатить к проверенной конфигурации; повторно запустить тесты после изменения поставщика. Результат
Результат: рабочая процедура и регрессионные проверки.
Вымышленный пример
Иллюстративная ситуация
Показательная ситуация: два клиента используют одного поставщика идентификации. Токен, действительный для первого, предоставляется API второго клиента.
Решение и ожидаемые доказательства
API отклоняет неправильную аудиторию, записывает трассировку без токена и не возвращает данных. Отказ становится регрессионным тестом.
Различение механизмов
| Механизм | Назначение | Проверка или ограничение |
|---|---|---|
| OAuth 2.0 | Делегирование доступа к ресурсам | Разрешения объектов на стороне сервера |
| OpenID Connect | Установление личности с помощью проверенного токена ID | Проверка эмитента, аудитории и транзакции |
| Сессия приложения | Поддержание авторизации приложения | Истечение срока действия, аннулирование и защита сессии |
Показатели управления
| Показатель | Что он измеряет | Первое действие |
|---|---|---|
| Исправление отказов | Запрещенные случаи фактически блокируются | Исправление каждого неожиданного принятия |
| Задержка отзыва | Время до исчезновения соответствующего доступа | Проверка сессий и токенов отдельно |
| Сбои проверки | Отклонения по причине и версии | Разделение атак и ошибок конфигурации |
Распространенные ошибки
- Путаница аутентификации с авторизацией
- Принятие любой аудитории после проверки подписи
- Регистрация широкого перенаправления URI
- Ведение журнала токенов для упрощения отладки
Часто задаваемые вопросы
Заменяет ли PKCE все элементы управления?
Нет. Он защищает обмен кодом в предполагаемом потоке; проверка токенов, перенаправления, авторизация бизнеса и сессии по-прежнему требуют проверки.
Является ли JWT разрешением?
JWT — это формат. Утверждения становятся пригодными для использования только после проверки и применения правил вашего API.
Следует ли создавать проверку с нуля?
Предпочтительнее использовать поддерживаемую библиотеку и документацию поставщика, а затем протестировать свою конфигурацию. Правильная библиотека все еще может быть настроена неправильно.
Официальные ссылки
Ссылки подтверждают метод. Адаптируйте проверки к вашему контексту; они не являются сертификацией. Оригинальные названия ссылок и исходные документы могут быть на другом языке.
