Блог

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

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

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

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

О чем я думаю, так это о реализации этого сценария:

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

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

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

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

Или, может быть, я что-то упускаю?

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

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

http://www.jhipster.tech