Есть три сервиса, работающих по OAuth 2.0. Service#0 - там основные данные пользователя. Сайт - это "морда" к Service#1, куда пользователь штатным образом с редиректами логинится через Service#0. Задача - подключить Service#2 к Service#1 (не к сайту, а именно к серверу), так чтобы Service#2 поимел ключ доступа к данным Service#0 для того же ресурса, что и Service#1. Другими словами - #1 хочет залогиниться на #2 через #0, подтвердив, что он и есть тот пользователь. Не могу понять flow, которым это кошерно организовать через OAuth.

Мое предположение костыльное. #1 получает токен для доступа у #0 путем стандартного Authorization Code Grant через сайт. Затем, когда надо, #1 сам регистрируется на #2 с client_credentials. И получает как бы ключ сессии. Потом просит у #0 некий код для #2 подтвердив себя своим же токеном, который у него уже есть. #1 отдаёт полученный код в #2, #2 получает у #0 по коду токен и записывает, что считать эту сессию с #1 аутентифицированной как вот тот пользователь, что он захватил у #0.

Но я вот сомневаюсь по поводу пункта "просит у #0 некий код для #2 подтвердив себя своим же токеном". Может есть стандартная последовательсность действий?

Хочу для некоего сервиса сделать дополнительные свистелки в виде отвязанных приложений. Как например приложения вконтакте. Собственно всё что надо им знать от основного сервиса - это то, что его пользователь сейчас изъявил желание сделать что-то от своего имени на выбранном допсервисе. Хочется это соответственно как-то вставить внутрь страницы основного сервиса. Вопрос - что модно в 2016 году? iframe говорят уже атата

Столкнулся с какой-то глупостью. Веб-приложение. Достаточно крупное. С ветвистыми модулями. От точки входа к модулю как передать конкретно данный для данный сессии коннект к базе данных? Сейчас все функции просто тащат за собой и передают дальше некий env.