Введение
Один API манипулирует аккаунтами, отвечает за хранение данных о пользователе и все привязки к соц сетям. Назовем его company, а API расположим: api.company.com
Появляется проект, его назовем project. API расположен по адресу api.project.com
Цель:
Для авторизации в project новый аккаунт создавать не нужно. Универсальный аккаунт для всех проектов находится в company. Концепция хабра с их TM - для локальный проектов аккаунт не нужен (а вот у проектов есть профиля).
Проблема:
Как выстроить архитектуру?
Какие средства для этого использовать?
Идея решения или как я себе это представляю:
На клиенте показывается окно авторизации, вводится логин пароль. Отправляется на API проекта: api.project.com/login...
Из API проекта делается запрос на API с аккаунтами: api.company.com/login...
Если все в порядке - выдается токен и возвращается в API проекта, сохранятеся и отправляется клиенту. Далее понятно, запросы идут с этим токеном.
P.S. Можно и напрямую делать запрос из клиента на api.company.com/login...
но мне показалось лучше не миксовать и вынести логику.
Дополнительная инфа:
API закрытое. Использовать буду или JWT или Oauth 2.0 c грантом владельца (не нужно будет показывать браузер и просить разрешение, понятное дело клиент доверенный). Все API пишу на Lumen.
Слова благодарности со слезами на глазах:
Практически уверен что идея - костыль, и есть уже изобретенный хороший велосипед.
Буду благодарен за любую помощь!
Иван Воробей
OpenID Connect ( openid.net/connect ) - стандарт аутентификации поверх протокола OAuth . Если говорить грубо, то создавался с целью заменить кнопочки Login by Google, Login by Facebook и прочие самописные протоколы аутентификации на базе OAuth на единое соглашение. Не путать с классическим OpenID, это совершенно разные вещи.
Станислав Макаров: тут нюанс в том, что будет запрос у пользователя разрешение. А нужно обычная доверенная авторизация. Только хранить все в единой точке.
Что скажешь насчет обычного jwt, и передачи токена проекту?
Иван Воробей ну в OIDC подписанный веб-токен и передаётся) Так что вполне можно и самому попробовать это реализовать. Стандарт можно использовать как ориентир, и выкинуть лишнее.
Подскажите, это для api подойдет? У меня цель сделать на клиентах ( не браузерах) sso, и цель не во входе один раз - а именно в том, что аккаунт универсален для все проектов.