Блог

Мы находимся в процессе создания клиентского приложения для организации с техническим стеком 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]

КОНФИДЕНЦИАЛЬНОСТЬ

Вы можете решить эти проблемы стандартным способом с помощью нескольких методов, хотя они требуют более сложного процесса:

• Используйте непрозрачные токены, которые не читаются интернет-клиентами и не раскрывают никакой конфиденциальной информации — см. Шаблон 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);
        }
    }
}