разделение основного объекта, полученного от провайдера oauth2, между пружинным и угловым - PullRequest
Новая
       17

разделение основного объекта, полученного от провайдера oauth2, между пружинным и угловым

0 голосов
/ 08 мая 2018

Я наткнулся на проблему с Spring Security и Angular.

В моем BE (приложении Spring Boot) есть определенные поставщики OAuth2, такие как Google, GitHub и Facebook.

Мой BE отлично работает с этими провайдерами, так как я могу аутентифицироваться на нужных провайдерах.

Проблема в том, что я пытаюсь отправить основной объект в FE (приложение Angular 6).

Я получаю неопределенное значение, когда пытаюсь подписать значение из остальной конечной точки. Я предполагаю, что это связано с тем, что Spring Servlet создает новый поток для запроса входа в систему. Я делаю запрос на вход в приложение Angular.

Я смотрел десятки уроков и очень много статей, но я просто не могу найти ответ. Если вы можете поделиться каким-то кодом о том, как это делается, или дать мне ссылку, поскольку я, безусловно, делаю глупую ошибку и, похоже, не могу найти ответ здесь.

Спасибо за понимание, хорошего дня. :)

1 Ответ

0 голосов
/ 09 мая 2018

Я предполагаю, что вы используете поток кода авторизации из вашего BE для аутентификации пользователя, который взаимодействует с вашим приложением FE Angular (в вашем примере). В противном случае вы будете пытаться аутентифицировать Клиента BE в потоке Клиента, и вам не нужно будет возвращать «основной объект» в приложение FE. Если мои предположения верны ... читайте дальше.

Поток кода авторизации выглядит следующим образом:

1) Пользователь каким-то образом выбирает провайдера аутентификации (например, Google), и этот выбор возвращается некоторой конечной точке в BE в качестве неаутентифицированного запроса.

2) Клиент BE получает этот запрос, предпочтительно перехваченный фильтром, и, поскольку запрос не аутентифицирован, перенаправляет браузер на конечную точку авторизации выбранного поставщика аутентификации.

3) Затем пользователь переходит к аутентификации у того провайдера, который после успешной аутентификации возвращает ответ, который перенаправляет браузер на конечную точку BE Client. Это перенаправление содержит параметр, который предоставляет код, который BE-клиент будет использовать для получения idToken, представляющего пользователя. На данный момент важно отметить, что браузеру не было возвращено ни одного ответа для этого перенаправления .

4) Затем клиент BE переходит к обычному HTTP-запросу на конечную точку токена поставщика вместе с полученным кодом авторизации. Затем провайдер возвращает idToken HTTP-ответ непосредственно клиенту BE. Все это происходит , пока браузер все еще ожидает ответа на последний редирект .

5) Затем BE-клиент обрабатывает idToken (проверка, проверка, данные пользователя, сеанс и т. Д.), И только после этого наконец отправит ответ в браузер , терпеливо ожидая с момента перенаправления кода. Этот ответ может содержать заголовок или cookie-файл с sessionId или токеном (по вашему выбору), который приложение FE сможет прочитать или использовать для данной цели.

Этот поток относительно прост в реализации и требует минимальной конфигурации SS. Вы должны сохранить конечную точку аутентификации BE Client с помощью allowAll (), иначе вы не сможете запустить этот поток. Кроме того, убедитесь, что, как только приложение FE. получил заголовок / cookie, все последующие вызовы должны обрабатываться как «аутентифицированные вызовы». Наконец, убедитесь, что вы документировали себя с точки зрения безопасности сеансов без сохранения состояния, а также безопасности файлов cookie и всегда используете HTTPS.

Джейк.

...