Facebook JS SDK не требуется секретный ключ приложения для аутентификации: насколько он защищен? - PullRequest
16 голосов
/ 17 февраля 2011

Когда я использую JS SDK от Facebook для аутентификации своего приложения (используя метод FB.init), все, что мне нужно, это мой идентификатор приложения.Для этого не требуется секрет моего приложения и / или ключ приложения.Однако, когда я использовал PHP SDK, для этого требовался секрет моего приложения (по крайней мере, в примере, который я использовал для изучения, использовались и идентификатор приложения, и секрет приложения).

Безопасно ли и рекомендуется использовать JS SDK для аутентификации?Как на самом деле происходит процесс аутентификации с JS SDK?

Спасибо, Vineet

Ответы [ 3 ]

3 голосов
/ 08 августа 2011

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

Новая версия JS SDK использует OAuth 2.0. Это хорошо задокументировано - за подробностями обращайтесь на сайт OAuth 2.0 .

Что касается вопроса о том, нужен ли SDK секрет приложения - у меня возникла небольшая путаница в связи с этим. На стороне сервера приложений библиотеки указывают, что JS SDK подписывает куки-файлы, используя секрет приложения (см. Функцию get_user_from_cookie в facebook-python sdk ) - однако мне совершенно неясно, как JS SDK может знать секрет приложения. Я предполагаю, что он может получить его динамически от FB, когда он общается с FB непосредственно в процессе аутентификации, но я не уверен.

(Изменить: я думаю, что JS SDK получает cookie, подписанный с секретом приложения напрямую от FB - JS SDK никогда не знает секрет приложения).

Не полностью отвечаю на ваш вопрос, но, возможно, пролив немного больше света на то, как это работает.

1 голос
/ 17 февраля 2011

Это НЕ безопасно, поэтому у вас есть параграфы " Проверка полей " и " Не проверка подписи " в расширенной регистрации документ:

Когда вы запрашиваете данные Facebook, мы проверьте поля формы перед упаковка их в signed_request. Это позволяет предположить, что все данные являются подлинными и сохраняет вам от необходимости проверять вещи. одна проблема, которая может возникнуть, это умный злоумышленник может изменить форму поля и представить их вам, тем самым предоставляя вам непроверенные данные.

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

1 голос
/ 17 февраля 2011

Другая проблема, о которой следует опасаться, - это не использовать объект пользователя FB, который вы получаете от клиента, для чего-либо на стороне сервера. Это потому, что кому-то было бы действительно легко создать скрипт, который вместо вызова fb.api '/ me' отправил бы в ваше приложение "поддельный" объект пользователя JSON с другим идентификатором пользователя. Если вы выполняете какую-либо обработку на стороне сервера для пользователя, то вам действительно нужно выполнить некоторую аутентификацию на стороне сервера, я думаю.

...