Токен JWT против токена сеанса для React Native и react Js

#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 или какой-либо службы аутентификации

Поток высокого уровня [![Поток][4]][4]

Поток

Ответ №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. Я обновил свой первоначальный ответ некоторыми моментами по этому поводу