SPA и простой бэкэнд на одном источнике с Oauth2 - способ использования http сессии - PullRequest
Новая
       13

SPA и простой бэкэнд на одном источнике с Oauth2 - способ использования http сессии

0 голосов
/ 01 апреля 2019

С помощью простого бэкэнда (например, Spring) и SPA front и провайдера аутентификации OAuth2, как правильно внедрить авторизацию на основе сеансов http?

Под термином «правильный» я подразумеваю способ выдать себя за пользователя за сервер для получения cookie-файла сеанса.

К сожалению, вокруг JWT - «масштабируемый, спокойный, без сохранения состояния». Но мое приложение будет использоваться очень немногими пользователями, и оно просто требует старой доброй безопасности, которая обеспечивается http-сессиями из коробки. Текущее «предложенное» решением Okta вызывает проверку каждого запроса API, поэтому каждый вызов имеет значительные накладные расходы, что приводит к небрежной производительности.

Предположим, что у нас есть приложение SPA, выставленное на myapp.com, а его бэкэнд - на прокси через myapp.com/api.

.

Я думаю о реализации этого сценария:

  1. пользователь посещает SPA (Angular, React, что угодно)
  2. SPA вызывает backend для деталей пользователя, 403
  3. SPA перенаправляет на oauth провайдера, например. Okta
  4. пользователь входит в систему oauth провайдера
  5. oauth-провайдер предоставляет токен на предъявителя и перенаправляет обратно в SPA
  6. SPA вызывает backend для сведений о пользователе, но с носителем сейчас
  7. Spring получает предоставленный токен oauth2, проверяет это в провайдере oauth, создает сеанс http и предоставляет файл cookie сеанса (JSESSIONID)
  8. SPA-вызовы на сервер автоматически заполняются cookie (мы говорим с прокси, так что это тот же домен)

или, может быть:

  1. пользователь посещает SPA (Angular, React, что угодно)
  2. SPA вызывает backend для сведений о пользователе, 403, поэтому backend перенаправляет к oauth провайдеру, например. Okta
  3. пользователь входит в систему oauth провайдера
  4. oauth перенаправляет обратно на сервер с токеном oauth2
  5. Spring получает предоставленный токен oauth2, проверяет его в поставщике oauth, создает сеанс http и предоставляет файл cookie сеанса (JSESSIONID) и перенаправляет в SPA
  6. SPA вызывает backend для пользовательских данных (автоматически заполняется cookie), 200

Существует ли готовая конфигурация? Похоже, что оба сценария требуют много работы и настройки на стороне безопасности весны. К сожалению, трудно найти какие-либо ресурсы, связанные с файлами cookie сеанса http, в сочетании с поставщиками SPA и oauth2.

А может я что-то упустил?

1 Ответ

0 голосов
/ 01 апреля 2019

JHipster реализует (более безопасный) второй сценарий (также известный как поток кода авторизации).Его реализация основана на поддержке OAuth в Spring Security.

Мы протестировали все с Keycloak и Okta, но он должен работать с любым IIDP, совместимым с OIDC.

http://www.jhipster.tech

...