Что касается OAuth 2.0: являются ли сторонние cookie файлы зависимыми?

При блокировании сторонних файлов cookie с использованием Google Chrome (последняя версия), создайте 27 Win7/PC, я видел, что почти все логины OAuth с других сайтов не работают, за исключением входа в систему с G+. Я уже подписал контракт с Google, так что cookie существует.

Это поведение, которое на самом деле является зависимостью OAuth2.0, требующей Сторонние файлы cookie должны быть включены?
Является ли это следствием преобладающей реализации OAuth?
Это что-то зависящее от клиента?
Это связано с тем, как Chrome определяет, что такое сторонние файлы cookie?

Спасибо всем за вашу помощь и время! Кажется, я не могу найти источники, которые разъясняют мне эту проблему.

Ответ 1

Для веб-приложений требуется некоторое хранилище локального хранилища ( "ДОЛЖНО..." ) с помощью спецификации OAuth 2.0 в качестве части защиты от подделки подпроса (CSRF). Спецификация предлагает куки или местное хранилище HTML5 специально, причем куки файлы являются распространенной реализацией, как показывают ваши наблюдения.

Ссылка RFC 6749 - OAuth 2.0 Authorization Framework мы находим (выделение добавлено):

Вопросы безопасности

Как гибкая и расширяемая структура, безопасность OAuth соображения зависят от многих факторов. Следующие разделы предоставить разработчикам рекомендации по безопасности, ориентированные на три профили клиентов, описанные в разделе 2.1: веб-приложение, приложение на основе агента пользователя и собственное приложение.

...

10,12. Подделка запросов на межсайтовый поиск

Подделка запросов на межсайтовый запрос (CSRF) - это эксплойт, в котором злоумышленник    заставляет пользователь-агент конечного пользователя-жертвы следовать вредоносному URI    (например, предоставленному пользователю-агенту в качестве вводящей в заблуждение связи, изображения или    перенаправление) на доверяющий сервер (обычно устанавливаемый через    наличие действительного cookie сеанса).

Атака CSRF против URI перенаправления клиента позволяет злоумышленнику    ввести свой собственный код авторизации или токен доступа, который может    в результате клиент использует маркер доступа, связанный с    злоумышленник защищает ресурсы, а не жертву (например, сохранять    информацию банковского счета жертвы на защищенный ресурс    управляемый злоумышленником).

Клиент ДОЛЖЕН внедрить CSRF-защиту для своего URI перенаправления.   Обычно это достигается путем запроса любого запроса, отправленного на    конечная точка URI перенаправления для включения значения, которое связывает запрос с    аутентифицированное состояние пользовательского агента (например, хэш сеанса    cookie, используемый для аутентификации пользовательского агента). Клиент ДОЛЖЕН    использовать параметр запроса состояния, чтобы доставить это значение до    авторизационного сервера при выполнении запроса авторизации.

После получения авторизации от конечного пользователя    сервер авторизации перенаправляет пользовательский агент конечного пользователя обратно    клиент с требуемым значением привязки, содержащимся в "состоянии",    параметр. Значение привязки позволяет клиенту проверить    действительность запроса путем сопоставления значения привязки с    аутентифицированный пользовательский агент. Значение привязки, используемое для CSRF    защита ДОЛЖНА содержать недопустимое значение (как описано в    Раздел 10.10) и состояние аутентификации пользователя-агента (например,    session cookie, локальное хранилище HTML5) ДОЛЖНО храниться в месте    доступный только клиенту и пользовательскому агенту (т.е. защищенному    политика одного и того же происхождения.