Несколько месяцев назад мы развернули Discourse (https://www.discourse.org)) вместе с нашей собственной платформой единого входа. В то время это был самый быстрый (не самый умный) способ выпуска этого приложения. Эта платформа полагаетсяна API (named CoreApi
) для аутентификации пользователей. У нас есть конечная точка аутентификации «oAuth», которая принимает имя пользователя / пароль и возвращает AccessToken (JWT) и RefreshToken.
Теперь мы хотим «поддержать» другой веб-сайт с именемMyPage
. Интересной особенностью MyPage является то, что он также использует CoreApi
для извлечения данных, относящихся к пользователям или клиентам.
С моей точки зрения, для поддержки MyPage
наша платформа единого входа должна будет вернуться«токен», чтобы веб-сайт мог аутентифицировать пользователя. Это вызывает несколько вопросов:
Передача токена с использованием HTTP-запроса Get не защищена вообще .кто перехватит запрос, может запросить наш API.
Весь поток звучит не очень естественно.
- Пользователь пытается получить доступ
MyPage
. - Если они не аутентифицированы, они перенаправляются на нашу платформу sso
- В нашем едином входе, если не аутентифицированы, они перенаправляются на страницу входа
- Если аутентификация прошла успешно, мы перенаправляем
MyPage
, и мы передаем «токен» (refreshToken, новый вид токена еще не уверен). - После перенаправления
MyPage
передает этот токен нашему API на повторный вход (двойная аутентификация) - Пользователь может использовать веб-сайт
Мне кажется, что мы движемся не в правильном направлении.
Вопросы:
- Как мы могли объединить нашу платформу SSO и аутентификацию API, требуемую в
MyPage
?Существуют ли какие-либо инструменты / передовые практики, которым нужно следовать? - Я уверен, что они представляют собой тонны веб-сайтов, использующих как API, так и SSO.Как они этого добиваются?
Примечания:
- Весь наш сайт написан на .net core
Спасибо за вашу помощь