У нас есть шлюз Api перед поставщиком аутентификации и микросервисами (серверы ресурсов). В этой архитектуре нам не нужно получать JWT по типу гранта authorization_code и запускать два вызова, поскольку у нас нет внешних клиентов oauth, и только клиент является шлюзом.
Существует пример приложения , реализованный Джо Грандджа для реализации oauth с облачной пружиной и Api-Gateway. Это потрясающе, но оно работает на основе веб-сессии и authorization_code grant-type.
Что это значит, паттерн с состоянием, между браузером и шлюзом у нас есть JSESSIONID и активный сеанс на стороне сервера в шлюз и использование сеанса между шлюзом и провайдером аутентификации (UAA) для хранения Authorization Request для получения кода и затем токена.
Я не знаю, какой смысл здесь иметь активные сеансы и использовать authorization_code, когда и auth_provider, и его клиент (шлюз) находятся в одном домене.
Дизайн, которым я являюсь мышление, основано на полностью безгосударственном образце. Браузер или мобильные приложения должны отправлять токен для каждого запроса в шапке. Мы избавляемся от аутентификации на основе cook ie, и CSRF может быть отключен, и ... также шлюзу не нужно выделять память для объектов сеанса. Мы можем иметь несколько экземпляров Auth-провайдера с одним шлюзом и т. Д. И т. Д. c.
Не должно быть никаких проблем для реализации этого с нуля, но мне интересно, поддерживает ли Spring OAuth2 неявный тип предоставления когда мы используем:
NoOpServerSecurityContextRepository.getInstance()
По умолчанию SecurityContextRepository в Spring равен WebSessionServerSecurityContextRepository, а в примере приложения, о котором я упоминал выше, когда я изменил его на NoOpServerSecurityContextRepository, я получаю исключение, потому что тип предоставления 'authorization_code' и spring должны хранить запрос в сеансе.
Итак, я ищу весной для реализации неявного типа предоставления.
Спасибо,