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

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

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

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

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

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

Обновление: янаткнулся наЭта статья, который обеспечивает схему подхода, который использует OAuth. Тем не менее, это не достаточно подробно для меня, чтобы действительно понять, как использовать это с OAuth 2. "

 davidrac08 нояб. 2012 г., 10:25
наткнулся на эту статью [supercollider.dk/2009/01/oauth-and-client-side-widgets-154], который обеспечивает схему подхода, который использует OAuth. Тем не менее, это не достаточно подробно для меня, чтобы действительно понять, как использовать это с OAuth 2.
 davidrac04 нояб. 2012 г., 18:26
Да. Javascript включен в HTML. Конечно, никакой секрет клиента не должен быть задействован. Это цель неявного потока OAuth 2.0. Я тоже не эксперт, и поэтому яя задаю этот вопрос.
 Arjan08 нояб. 2012 г., 20:33
Эта статья (фиксированная ссылка) хорошая находка! Это "Чтобы убедиться, что потребитель выполнил файл JavaScript, поставщик услуг может сохранить токен подтверждения в файле cookie браузера при запросе файла. Когда страница авторизации загружена, поставщик услуг может убедиться, что указанный токен запроса соответствует токену подтверждения в файле cookie. " кажется твердым для меня. (Предполагая, что ваши пользователи достаточно умны, чтобы вводить только свои учетные данные на вашем сайте.) Какие-либо особенности, которые вызывают у вас проблемы?
 davidrac04 нояб. 2012 г., 15:26
Это мое требование. Мне нужно аутентифицировать как клиента, так и владельца ресурса. Я предположил, что яВам нужно будет использовать неявный поток OAuth 2.0 и сравнить зарегистрированный URL обратного вызова с URL в вызове. Тем не менее, это часть объяснения, которое яищу ...
 Arjan04 нояб. 2012 г., 17:35
Итак, учитывая васповторяю слововеб-виджет и вашпредыдущий пост: какой-то JavaScript включает в HTML? (Следовательно: любой клиентский токен будет виден в исходном коде HTML и может быть использован любым, кто хочет включить виджет в свой сайт? Хотя я не эксперт.)
 Arjan04 нояб. 2012 г., 15:22
веб-сайты, которые были зарегистрированы на моем сайте " - Вы предполагаете, что можете использовать OAuth для своего клиента?аутентификация? Или только для посетителя? И как вы создаете этот виджет? (JavaScript или что-то на клиентес сервера?)
 Arjan22 нояб. 2012 г., 23:41
Я думал, что разместил это раньше, но, видимо, нет: см. ТакжеJS-скрипт для стека Exchange а такжеобщая документация для некоторых идей.

Ответы на вопрос(1)

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

Я собираюсь предположить, что вы не катите своего собственного поставщика OAuth 2.0 с нуля, если вы - молодец, в противном случае вы должны использовать что-то офигенноепривратник сделать это для вас.

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

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

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

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

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

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

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

Поток такой:

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

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

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

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

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

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

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

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

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

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

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

 Arjan21 нояб. 2012 г., 15:59
URL реферала -Статья ОП нашел использованиеif(document.domain=='the-registered-domain.com') Любая причина, почему вы полагаетесь на REFERER вместо этого? (Это может быть пустым.)Ваш JS-код ищет файл cookie сеанса " - это нужно, что печеньебыть НЕ HttpOnly, Но также, JavaScript будет работать на разработчикас доменом, и не может получить доступ к cookie сеанса? Арен»т шаги 4 и 5 только один?
 Arjan21 нояб. 2012 г., 20:09
Я не былНе говоря о слиянии текста :-) Вместо этого я имел в виду: как JavaScript может даже получить доступ к этому cookie, так как он возник из другого домена? Я могу понять, что это работает, когда 4/5 действительно один шаг, как "Ваш код JS проверяет связь с веб-сайтом, поэтому браузер также отправляетCookie-X» который возник из вашего домена. Ваш сервер проверяет cookie-файлы и отвечает контентом для просмотра. " Но не из кода JavaScript? Кроме того, я чувствуюif(document.domain== ...) является одной из самых важных деталей в этой связанной статье; без этого код будет успешнымлюбой Веб-сайт?
 Varun Vohra22 нояб. 2012 г., 08:54
Возможно, что-то из этого было неясно в ответе, но я хотел дать ответ с обзором, объясняя все это примерами кода, это выходной проект по публикации 5-страничного учебника!
 davidrac22 нояб. 2012 г., 12:22
Большое спасибо за подробный ответ! Как вы уже догадались, я использую привратника. Один момент, который я не мог понять из всех комментариев, как JS работает в моем клиентеs домен читает куки, которые были установлены с моего домена. Можете ли вы уточнить это?
 Varun Vohra21 нояб. 2012 г., 16:18
@Arjan спасибо за указание на httponly - это не такударить меня в то время. Я'мы добавили это. document.domain vs referrer - это не дебат imho. Я'мы добавили оба. Я не хотел бы делать проверку на стороне клиента независимо, поэтому JS может отправить черезdocument.domain Значение и на сервере мы можем проверить как на законность. О, также я объединил 4 и 5 ... длинные ответы немного утомительны в SO редакторе.
 davidrac15 дек. 2012 г., 12:34
Кажется, что это довольно спорный. Это еще одно сообщение от @Arjan, которое имеет отношение к делу:stackoverflow.com/questions/5472668/..., Так как я неЯ пока не смогу реализовать ни одно из решений,пока не принимаю :(
 Arjan21 нояб. 2012 г., 20:25
Нравится: на шаге 1, 2 и 3 вы неПроверьте файл cookie. Таким образом, это может быть код на стороне сервера с поддельным REFERER. На шаге 4 вы непроверить наif(document.domain== ...), Таким образом, несмотря на то, что получение файла cookie указывает на то, что запрос был отправлен именно браузером, вы не можете быть уверены, что именно браузер выполнил первые 3 шага? (Я чувствую, что это именно те недостатки, которые решает связанная статья?)
 Varun Vohra22 нояб. 2012 г., 08:53
@ Arjan Совсем нет! Если вы используете OAuth 2.0, вам нужно будет отправлять токен доступа с каждым запросом независимо! Я'мы оставили эту часть целиком, потому что это стандартная практика oa2 ... первые 3 шагаНе нужно проверять наличие cookie, потому что приложение будет отправлять маркер доступа к конкретному приложению вместе с каждым запросом ... независимо от того, использует ли разработчик клиентскую сторону или серверные потоки для oa2! и на шаге 3 отправленные вами js будут сняты (в rails-ресурсах они по умолчанию находятся в производстве), поэтому вы знаете, что на шаге 4 источником является отправленный вами js.
 Arjan22 нояб. 2012 г., 23:33
Извините, я действительно думаю, чтобы не использовать ключ API на другом сайтеа также чтобы остановить XSS, необходимо проверить домен в коде JavaScript, чтобы убедиться, что токен доступа не установлен на других доменах,а также что второй cookie-файл (из вашего домена) должен быть установлен на том же этапе, на котором извлекается этот JavaScript. Кроме того, я нене вижу, какустановка cookie на сайт, который встраивает виджет защищает что-либо, так как этот cookie никогда не будет отправлен обратноваш веб сервер?
 Varun Vohra22 нояб. 2012 г., 08:55
@Arjan Также жемчужина, которую я посоветовал, имеет поддержку для всего этого основного совершенства oa2, испеченного прямо в ...github.com/applicake/doorkeeper/wiki/Supported-Features
 Varun Vohra22 нояб. 2012 г., 14:02
@davidrac взгляните на этот вопрос и ответstackoverflow.com/questions/402348/..., Кроме того, вы можете использовать небольшой Iframe (это то, что делает Facebook), вы можете прочитать об этом здесьstackoverflow.com/questions/4701922/..., И если у вас возникнут проблемы с IEstackoverflow.com/questions/13473287/...

Ваш ответ на вопрос