Я изучаю, что нужно сделать для создания приложения с единым входом, которое можно использовать для приложений, состоящих из статических клиентов в паре с отдельными API-интерфейсами.
Мое (вероятно, неправильное) понимание состоит в том, чтопоток такой службы работает примерно так:
1 Пользователь запрашивает статический ресурс HTML / JavaScript из домена A
2 Asбраузер загружает статический ресурс (HTML-страница со встроенным JavaScript), XHR-запрос отправляется на сервер B. Сервер B является сервером аутентификации - он будет искать cookie в запросе со страницы HTML (источник A), иесли он не найдет его / или если файл cookie не содержит действительного токена, он вернет ошибку
3 JavaScript на странице HTML будет либо успешным, либоошибка. В случае ошибки пользователь будет перенаправлен на страницу входа, связанную с сервером B, и с URL-параметром redirect, который позволит странице входа на сервер B перенаправить обратно на сервер A при успешном входе: server-b/login?redirect=server-a
4 Затем, когда пользователь вошел в систему на сервере B, JavaScript на странице входа в систему для сервера B вызовет перенаправление на сервер A (и в результате будет возвращен тот же статический веб-сайт)).
Затем, когда HTML-страница, возвращенная с сервера A, снова загружается, XHR-запрос к серверу B будет переделан, но на этот раз с сообщением об успешной аутентификации.
При использовании этого подхода,Я не понимаю, как получить доступ к токену аутентификации, предоставленному cookie-файлом для сервера домена B, с ресурса, обслуживаемого сервером A. Это означает, что при выполнении запросов XHR к моему API со статической веб-страницы я не могу передатьрезультат аутентификации моего взаимодействия с сервером B.
Но я МОГУ ДАТЬ статической странице (обслуживаемой с сервера A) доступ к cookie, если этот cookie присутствовал в URL как параметр, когда происходит перенаправление с сервера B.
Является ли это приемлемым способом реализации единого входа?