13 521
правка
Изменения
Нет описания правки
По идее передача токена через браузер (через обратный редирект с Authorization URL’а) предусмотрена непосредственно в самом OAuth2 стандарте, так что плагины должны её поддерживать. Только стандарт требует HTTPS, а то токены голые по сети летают.
Еще есть такой протокол как CAS — но реализации всего две, https://github.com/rubycas/rubycas-server и https://wiki.jasig.org/display/CAS/Home, обе в виде отдельных серверов, один из которых на Ruby. Смысла это использовать, наверное, нет. OpenID — тоже, так как устарел и вообще больше склонен к ошибкам взаимодействия. Принцип везде по сути тот же (да если и самому написать — он останется тот же), а так как OAuth2 более популярен (много готовых плагинов под разные CMS и языки) и решает более широкий спектр задач, лучше брать его, либо OpenID Connect, который является его надмножеством (с OpenID Connect-сервером можно работать как с OAuth2 сервером). Разве что для публичного сайта следует задуматься о реализации механизма (2), описанного выше.
Для SSO между разными приложениями применение OAuth2 вполне нормальное. Однако, если у вас одно приложение, поделённое на микросервисы — то вот для шаринга сессий между микросервисами OAuth2 юзать реально странно. Так как по идее, наверное, просто должен быть отдельный «сервис сессий» или «сервис юзеров», логически являющий собой разделяемое между всеми компонентами приложения хранилище сессий и инкапсулирующее всю логику работы с пользователями (бизнес/не бизнес — всю), и все остальные компоненты должны в него ходить просто, без всяких Authorization URL, рефреш-токенов, консьюмеров и т. п.
