Пытаюсь структурировать теорию по реализации SSO на базе OAuth2 и понимаю что не понимаю этот процесс до конца.
У нас есть несколько независимых веб приложений, одно из них (например A)выступает как OAuth2 Authorization и Resource server.
Второе веб приложение(например B) должно всю аутентификацию/авторизацию своих пользователей проводить через первое приложение которое выступает как SSO провайдер.
Взаимодействие клиентов с приложением B происходит только через REST endpoints которые оно предоставляет.
Задача — засекьюрить REST endpoints приложения B через OAuth2 приложения A.
Как должен выглядеть этот процесс, что после успешного процесса авторизации я должен сохранять на стороне приложения B для того что б все последующие запросы от пользователя к приложениею B не валидировать с приложением A?
Или же я в любом случае должен валидировать access token который будет приходить от пользователя приложению B с приложением A ?
Расскажите пожалуйста как правильно организовать этот процесс в вышеуказанной архитектуре системы. Спасибо
Здравствуйте, brunoid, Вы писали:
B>Пытаюсь структурировать теорию по реализации SSO на базе OAuth2 и понимаю что не понимаю этот процесс до конца.
B>У нас есть несколько независимых веб приложений, одно из них (например A)выступает как OAuth2 Authorization и Resource server.
B>Второе веб приложение(например B) должно всю аутентификацию/авторизацию своих пользователей проводить через первое приложение которое выступает как SSO провайдер.
B>Взаимодействие клиентов с приложением B происходит только через REST endpoints которые оно предоставляет.
B>Задача — засекьюрить REST endpoints приложения B через OAuth2 приложения A.
B>Как должен выглядеть этот процесс, что после успешного процесса авторизации я должен сохранять на стороне приложения B для того что б все последующие запросы от пользователя к приложениею B не валидировать с приложением A?
B>Или же я в любом случае должен валидировать access token который будет приходить от пользователя приложению B с приложением A ?
B>Расскажите пожалуйста как правильно организовать этот процесс в вышеуказанной архитектуре системы. Спасибо
И так, все не так сложно как пишется в
манулах 
OAuth — это только авторизация, поэтому если Вы используете OAuth SSO, только как SSO не надо использовать OAuth. Если сервер B это Ваш сервер и вы его "пилите", зачем такой overhead вообще?
Но если Вы решили что нужен:
Есть несколько подходов именуются как grand_type:
— если пишете своего клиента, тогда дешевле пользоваться 'grant_type:password' — в один вызов получаете токен
— для сторонних клиентов со своим сервером лучше использовать 'grant_type:authorization_code'
— для простых сторонних клиентов (мобилка, десктоп, джаваскрипт) лучше всего 'grant_type:implicit'
По OAuth 2 простыми словами
тут
По спеке не указано стоит ли делать Authorization server & Resource server вместе, но т.к. у Вас планируется SSO, лучше если Authentication Server будет сам по себе, т.е. в Вашем случае это должно быть три сервера, т.к. в случае нового релиза Resource Server-а вся система будет недоступна т.к. Authorization server рестартует, хотя и не менялся. И вообще когда дело дошло до SSO, то обычно такие вещи не разарабатывают, их настраивают, для этого оно и придуманно.
Теперь еще про токен и запросы на Autherization Server. Для начала попробуйте простой вариант, токен всегда посылается Auth серваку, если будут проблемы связанные с сетью (скоростью по сети), можно подумать о том чтобы рассшарить алгоритм сверки и валидировать локально. (Пока такого не делал, но слушал презентацию от CloudFoundry они такое рекомендовали).
П.С.
Мне кажется, что Вы не до конца понимаете зачем нужен OAuth. Еще раз, если речь идет о независимых серверах, которые Вы сами пишете, лучше подумать о простом SSO. Просто в спеке по OAuth нет понятия пользователя — это ресурс. А пользователь в спеке OAuth (client) — это третья сторона, которая хочет воспользоваться чужим ресурсом. Если вы пишете свои сервера чужих не должно быть.
