Смешивание кода авторизации и неявного типа гранта в OAuth2

У меня есть некоторые вопросы для следующего потока с использованием OAuth2:

webapp1.xyz.com - это зарегистрированный клиент с типом разрешения кода авторизации, здесь текущий поток:

  1. Пользователь вошел в систему и перенаправлен с авторизационным кодом на webapp1.xyz.com
  2. webapp1.xyz.com обменять код авторизации для токена доступа и сохранить его на сеансе
  3. стороне сервера webapp1.xyz.com необходимо совершать вызовы на webapp2.xyz.com api, передавая токен доступа
  4. webapp1.xyz.com имеет SPA, где ajax вызывает endupa.xyz.com api endpoint (передача запросов cookie сеанса в запрос)
  5. Пользователь вышел из системы, сеанс разрушен

Существует предложение от кого-то сделать вызов ajax, используя токен доступа (неявный грант), вместо файлов cookie сеанса. Это даже возможно смешивание кода авторизации и неявного типа гранта? Может быть, я что-то смешиваю, я не вижу причин, почему использование неявного типа гранта для части ajax.

0
источник поделиться
1 ответ

Это даже возможно смешивание кода авторизации и неявного типа гранта?

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

Итак: SPA javascript> приложение webapp1.xyz.com> приложение webapp2.xyz.com.

В терминах Oauth2.0 ваше клиентское приложение SPA будет клиентом, а webapp1 и webapp2 будут ресурсами. клиент в идеале будет использовать неявный грант, чтобы получить токен доступа, как оптимизированный поток для публичного клиента javascript.

Если возможно, возможно, посмотрите на гибридный поток - OAuth2 и OpenID Connect - вместо потока кода авторизации.

Используя гибридный поток, webapp1 получит токен в настоящее время, но он также получит идентификационный токен, который он сможет передать обратно в SPA.

Маркер ID предназначен для использования клиентом для целей аутентификации - этот токен идентификатора может выполнять ту же работу, которую выполнял cookie сеанса (т.е. аутентификация между бэкэнд SPA и SPA). И токен доступа будет безопасно храниться на сервере webapp1 вдали от SPA.

+2
источник

Связанные вопросы


Похожие вопросы

Посмотрите другие вопросы по меткам или Задайте вопрос