Как реализовать веб-виджет с OAuth 2.0

Я хочу создать веб-виджет, который будет отображать информацию с моего сайта.

Виджет будет включен в HTML-сайт клиента с использованием JavaScript и должен использоваться только для моих клиентов - веб-сайтов, зарегистрированных на моем сайте.

Информация в виджетах должна быть конкретной для пользователя, который в настоящее время посещает клиентский сайт.

Итак, мне нужно аутентифицировать как клиента (владельца веб-сайта), так и владельца ресурса (посетителя сайта). Кажется, это хорошо сопоставимо с OAuth 2.0, но я не смог найти полный пример или объяснение для такой реализации.

Любые ресурсы или указатели на такую ​​информацию будут оценены.

Обновление: Я наткнулся на в этой статье, в котором содержится схема подхода, использующего OAuth. Тем не менее, для меня недостаточно детально понять, как использовать это с OAuth 2.

ОТВЕТЫ

Ответ 1

Есть много крупных организаций, которые это сделали, и мне грустно не видеть других ответов на этот вопрос, так как это такой важный веб-шаблон.

Я предполагаю, что вы не катаетесь на своем собственном провайдере OAuth 2.0 с нуля, если вы - хорошо сделано, иначе вы должны использовать что-то вроде kicka, например Doorkeeper, чтобы сделать это для вас.

Теперь в OAuth 2.0 у вас есть следующие объекты:

  • Пользователи, зарегистрированные на вашем сайте
  • Приложения, зарегистрированные на вашем сайте (которые подписываются на ваш oauth2)
  • Пользовательские разрешения, которые являются списком приложений, которые пользователь разрешил
  • Разработчик (который потребляет ваш API/виджеты auth и создает приложение)

Первое, что нужно отметить: у вас должно быть имя домена, связанное с каждым приложением. Поэтому, если разработчик регистрирует маркер/секретный код API на вашем веб-сайте, созданное им приложение сопоставляется с доменом уникальный.

Теперь я полагаю, что поток для приложения для аутентификации пользователей через ваш сайт уже понятен. При этом вам не нужно много работать, чтобы это работало.

Когда приложение отправляет пользователя на ваш сайт (для входа), вы помещаете cookie сеанса на компьютер пользователя. Позволяет называть это "Cookie-X".

Теперь пользователь аутентифицируется вашим сайтом и возвращается к Приложению. Там мы хотим показать пользовательский виджет с информацией, относящейся к этому пользователю.

Разработчику необходимо будет скопировать какой-нибудь код в это приложение.

Поток выглядит следующим образом:

  • Код будет содержать URL-адрес вашего сайта с его идентификатором приложения (не секретным), который он получил при регистрации своего приложения на вашем веб-сайте.

  • Когда этот код запускается, он будет пинговать ваш сайт своим приложением. Вам необходимо проверить, что AppID с вашей базой данных, и дополнительно проверить, что URL-адрес реферера - это тот же домен, что и тот, который зарегистрирован на вашем веб-сайте для этого AppID. Изменить: Альтернативно или дополнительно код может проверяться на document.domain и включать его в пинг на ваш сайт, что позволяет проверить, что запрос пришел из домена, зарегистрированного с данным AppID.

  • Если это правильно, вы ответите каким-то кодом JS.

  • Ваш JS-код ищет файл cookie сеанса, который был установлен вашим веб-сайтом, когда пользователь выполнил вход. Если этот файл cookie найден, он возвращается на ваш сайт с сеансом, и ваш сайт отвечает настраиваемым контентом.

Изменить:, как по праву упоминается в комментарии, cookie должен быть HttpOnly для защиты от обычных атак XSS.

Дополнительные примечания

Причины этого - безопасный подход:

  • AppId и доменное имя являются достаточно хорошей комбинацией для проверки того, что другие люди не получают эту информацию. Даже приложение appId видно в источнике приложений html, доменное имя должно быть подделано любым, кто пытается использовать кого-то еще AppID.

  • Предполагая, что кто-то принимает AppID, который не является его, и пишет код для подмены имени домена реферера при запросе вашего виджета, он все равно не сможет увидеть какую-либо информацию. Поскольку вы показываете конкретную информацию о пользователе, виджет будет отображаться только в том случае, если ваш веб-сайт может найти файл cookie сеанса, который он разместил в браузере пользователей, который не может быть действительно подделан. Есть способы, как захват сеансов и т.д. Но я думаю, что это выходит за рамки этого вопроса.

Другие методы Просто взглянув на социальные плагины Facebook, вы можете сказать, что есть другие варианты.

Например, можно использовать iframe. Если вы попросите разработчика добавить Iframe к его приложению, вы можете даже уменьшить несколько из упомянутых выше шагов. Но вам придется добавить JS вместе с ним (за пределами iframe), чтобы захватить правильный домен и т.д. И, конечно же, с точки зрения доступности и интерфейса я не очень-то найден в Iframes.