#reactjs #react-native #oauth-2.0 #openid-connect
#reactjs #react-native #oauth-2.0 #OpenID-подключение
Вопрос:
Мы находимся в процессе создания клиентского приложения для организации с техническим стеком react js для портала и react-native для мобильных устройств. Во время обзора было предложено использовать пользовательский сеанс на основе идентификатора сеанса вместо токена JWT.
Мы также хотим использовать поток OIDC для аутентификации и OAUTH2.0 для авторизации API, поскольку есть предложения как для JWT, так и для идентификатора сеанса, каждый из которых имеет свои плюсы и минусы. Команда безопасности настаивает на идентификаторе сеанса по причинам, указанным ниже
- JWT громоздкий, не подлежащий отзыву JWT опасны JWT vsSession Каким должен быть наш выбор для архитектуры безопасности
- Нужен ли нам еще идентификатор сеанса для отслеживания
- Токен, используемый для OIDC, не может быть отправлен в пользовательский интерфейс, поскольку он содержит информацию о конфиденциальности и безопасности
- должны ли мы использовать JWE?
- Можем ли мы иметь хэш токена или идентификатор корреляции, соответствующий токенам OIDC, и выполнять поиск при каждом вызове от клиента к серверной части, чтобы браузеру или клиентскому приложению не нужно было знать токены OIDC?
- Действительно ли нам нужна специальная служба аутентификации, может ли самого API Gw вместе с любым OIDC быть достаточно для реализации безопасности end2end без необходимости написания spring base или какой-либо службы аутентификации
Ответ №1:
КОНФИДЕНЦИАЛЬНОСТЬ
Вы можете решить эти проблемы стандартным способом с помощью нескольких методов, хотя они требуют более сложного процесса:
- Используйте непрозрачные токены, которые не читаются интернет-клиентами и не раскрывают никакой конфиденциальной информации — см. Шаблон Phantom Token для того, как это работает.
- В браузере используйте только защищенные файлы cookie (SameSite = strict, только HTTP, зашифрованные AES256), которые могут содержать непрозрачные токены. Посмотрите шаблон обработчика токенов, в котором есть React SPA, который вы можете запустить, и API-интерфейс обработчика токенов узла, который вы можете подключить.
Обычно эти учетные данные в Интернете ведут себя как идентификаторы сеанса, которые также непрозрачны, но вы используете стандартный OAuth, и ваши API по-прежнему завершают авторизацию с помощью токенов доступа JWT, поддающихся цифровой проверке.
ШАБЛОН ОБРАБОТЧИКА ТОКЕНОВ
Для SPA идея состоит в том, чтобы включить подобную настройку, при которой вы подключаете (и, возможно, адаптируете) компоненты обработчика токенов с открытым исходным кодом, вместо того, чтобы разрабатывать их самостоятельно. Этот шаблон должен работать с любым сервером авторизации:
Основные преимущества заключаются в следующем — смотрите Эти ресурсы Curity для получения дополнительной информации:
- SPA использует только самые надежные
SameSite=strict
файлы cookie, без каких-либо токенов в браузере - SPA может быть развернут во многих глобальных местоположениях через сеть доставки контента
- По умолчанию файлы cookie используются только для Ajax-запросов к API, что дает SPA наилучший контроль над аспектами удобства использования
ПОТОКИ API
При вызове API потоки работают следующим образом и обычно включают обратный прокси, размещенный перед API, так что код API остается простым:
- Веб-клиенты отправляют защищенный файл cookie, а расшифровка файла cookie получает непрозрачный токен. Затем второй плагин получает JWT из непрозрачного токена и пересылает его в API.
- Мобильные клиенты отправляют непрозрачный токен по тем же путям API, и в этом случае плагин для расшифровки файлов cookie ничего не делает. Затем второй плагин получает JWT из непрозрачного токена и пересылает его в API.
Обратите внимание, что клиент все равно может получить expires_in
поле, если он хочет выполнить оптимизацию для проверки срока службы токенов доступа, но я всегда советовал против этого, а вместо этого просто надежно обрабатывать 401-е в клиентах, например:
private async fetch(method: string, path: string): Promise<any> {
try {
// Try the API call
return await this.fetchImpl(method, path);
} catch (e) {
if (!this.isApi401Error(e)) {
throw ErrorHandler.handleFetchError(e);
}
await this.oauthClient.refresh();
try {
// Retry the API call
return await this.fetchImpl(method, path);
} catch (e) {
throw ErrorHandler.handleFetchError(e);
}
}
}
Комментарии:
1. Спасибо за ответ. Есть ли у нас аналогичный для веб-сервера Apache 2-й вопрос — если у нас есть API Gateway, должен ли он быть интерфейсным с веб-сервером, чтобы любой запрос, обращенный к Интернету, поступал на веб-сервер, а затем отправлялся на API Gateway?
2. Идея шаблона обработчика токенов заключается в том, что вы можете размещать статический веб-контент где угодно, и для этого может потребоваться другое развертывание API. Вы можете обслуживать веб-контент через Apache — или вы можете обслуживать его через стороннюю сеть доставки контента — на ваше усмотрение, в зависимости от того, что вы предпочитаете. Конечно, все запросы API, связанные с защищенными данными, должны проходить через ваш шлюз API.
3. Гэри, спасибо за ясность — Webserver httpd — для размещения статического содержимого — Webserver — mod_auth_oidc — если мы используем для использования токенов, это действует как конфиденциальный клиент для IDP, поскольку хранение клиентского секрета — API GW предназначен для получения защищенного запроса, который мы получаем через веб-сервер к API GW Вопрос для любого APIВызов, должны ли мы переходить через сам Mod_Auth_OIDC, а затем обращаться к API Gateway или напрямую к APIGW? — Шаблон обработчика токена требует, чтобы внутренний компонент перехватывал и переводил токен, полученный из SPA или браузера [непрозрачный Cookie], в понятный токен API GW — я прав
4. Mod_Auth_OIDC является уважаемым компонентом — если вы используете его, он выполнит всю обработку секретных данных клиента и файлов cookie для вас, чтобы избежать необходимости писать свой собственный веб-сайт. Возможно, он лучше всего подходит для ваших нужд. Шаблон обработчика токенов — это немного другой подход, когда вы подключаете API, затем SPA выполняет собственные перенаправления и может быть развернут в CDN. Вы будете использовать только один из этих вариантов, поэтому выбирайте тот, который, по вашему мнению, лучше всего соответствует вашим требованиям.
5. Я обновил свой первоначальный ответ некоторыми моментами по этому поводу