Как безопасно конвертировать токены Open ID Connect в файлы cookie - PullRequest
Новая
       91

Как безопасно конвертировать токены Open ID Connect в файлы cookie

2 голосов
/ 13 февраля 2020

У нас есть клиентское приложение, которое мы хотели бы включить SSO через OID C. Клиентское приложение представляет собой SPA с выделенным внутренним API. В настоящее время проверка подлинности осуществляется с помощью файлов cookie, а авторизация выполняется на бэкэнде в зависимости от пользователя Auth_Cook ie. После завершения аутентификации OID C мы хотели бы продолжить использование этих существующих локальных кодов ie на основе cook / logi c, что также избавляет от необходимости хранить токены в SPA.

После завершения потока аутентификации с кодом PKCE интерфейсный SPA получил бы ID_Token и Access_Token непосредственно от конечной точки /token OP. Чтобы перейти от ID / Access_Token к Auth_Cook ie, подход может быть следующим:

  1. Front-end SPA выполняет внутренний вызов API для аутентификации (например, /authenticate), передавая Access_Token
  2. Back-end проверяет Access_Token и выдает Auth_Cook ie

Поскольку ID_Token предназначен только для клиентского приложения (которое в данном контексте является интерфейсным SPA), мой Предполагается, что он не играет никакой роли в этой последовательности (хотя логически вы могли бы подумать, что вызов конечной точки /authenticate внутреннего API должен предоставлять что-то похожее на учетные данные, например, ID_Token).

Имеет ли смысл вышеуказанный подход и есть ли какие-либо проблемы безопасности / проблемы с этим? Существуют ли альтернативные / лучшие подходы для существенного преобразования внешнего идентифицированного контекста OID C в файлы cookie?

Буду признателен за любую информацию или помощь. Спасибо.

Ответы [ 2 ]

0 голосов
/ 13 февраля 2020

Спасибо за интересную дискуссию, Шерман - вы заставили меня понять, что я не совсем правильно все делаю, поэтому я обновил некоторые из своих вещей.

ВАРИАНТ 1 - ПЕЧЕНЬЕ

Это может иметь большой смысл, особенно если вам пока не нужны междоменные возможности. Полная приверженность тому, чтобы не иметь печенья, также может быть большой работой.

ВАРИАНТ 2 - НЕОБЫЧНЫЙ С ЖЕЛАМИ, ХРАНЕННЫМИ В ПАМЯТИ

Можно создать СПА без печенья и по-прежнему иметь дело с проблемами юзабилити, такими как обновление пользователем страницы без необходимости повторного входа в систему. У него есть предварительное условие на сервере авторизации, который должным образом поддерживает параметр prompt = none.

ВАРИАНТ 3 - УДОБНО С ХРАНЕННЫМИ ЖЕЛЕЗАМИ HTML5 ХРАНЕНИЕ СЕССИИ

Как мы уже говорили, многие не считают это безопасным, поэтому лучше избегать его, если это возможно. Вы можете рассмотреть возможность его использования, если ваш Сервер авторизации не поддерживает prompt = none.

0 голосов
/ 13 февраля 2020

Я думаю, было бы проще сделать так, чтобы ваш бэкэнд обрабатывал перенаправление аутентификации - чтобы он стал клиентом OAuth2 вместо вашего SPA. Вашему SPA не нужны токены, и вам не нужно будет передавать токен доступа на сервер. Бэкэнд-обработчик, который получит код авторизации, получит токены и создаст кулинарную аутентификацию ie (со всеми параметрами безопасности).

Если вам нужно сохранить SPA в качестве клиента OAuth2, то предлагаемое вами решение вероятно хорошо.

...