Только для № 1 – трехсторонняя авторизация с использованием потока кода авторизации.

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

Значение состояния обычно должно быть псевдослучайным недопустимым значением. Простое значение может быть сгенерировано как int с функцией rand () в PHP, хотя вы могли бы стать более сложными, чтобы обеспечить большую уверенность.

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

Дополнительная информация содержится в документе модели угрозы OAuth 2.0: http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00

В частности, см. Раздел о защите CSRF: http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-10.12

Может быть полезно выполнить пример использования CSRF, чтобы понять, как параметр состояния смягчает такую ​​атаку. В этом примере Мэллори атакует, а Алиса – жертвой .

Атака

1. Мэллори посещает веб-сайт какого-либо клиента и запускает процесс авторизации этого клиента для доступа к некоторому поставщику услуг с использованием OAuth

2. Клиент запрашивает у поставщика услуг разрешение на запрос доступа от имени Мэллори, который предоставляется

3. Мэллори перенаправляется на сайт поставщика услуг, где она обычно вводит свое имя пользователя / пароль для авторизации доступа

4. Вместо этого Мэллори ловушки / предотвращает этот запрос и сохраняет его URL

5. Теперь Мэллори как-то заставляет Алису посетить этот URL. Если Алиса зарегистрирована у поставщика услуг со своей учетной записью, ее учетные данные будут использованы для выдачи кода авторизации

6. Код авторизации обменивается на токен доступа

7. Теперь учетная запись Мэллори на клиенте имеет право доступа к учетной записи Алисы у поставщика услуг

Итак, как мы можем предотвратить это, используя параметр state ?

профилактика

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

2. Это значение передается поставщику услуг при перенаправлении с шага три выше

3. Теперь, когда Мэллори получает Алису, чтобы посетить сохраненный URL (шаг пять выше), этот URL-адрес включает параметр state сгенерированный с информацией о сессии Мэллори

4. Код авторизации выдается и отправляется клиенту в сеансе Алисы вместе с параметром state Мэллори

5. Клиент генерирует новое значение state основе информации о сеансе Алисы и сравнивает ее со значением state которое было отправлено обратно из запроса авторизации поставщику услуг. Это значение не соответствует параметру state в запросе, поскольку это значение state было создано на основе информации о сессии Мэллори , поэтому оно отклонено.

Злоумышленник не должен иметь возможность генерировать значение состояния для любого конкретного пользователя и, следовательно, обход пользователя при посещении их URL-адреса авторизации не влияет.

Поскольку «состояние» – это просто случайная строка, сделать что-то подобное нужно, чтобы сделать трюк:

 $state = md5(uniqid(rand(), TRUE)); 

Просто не забудьте сохранить его на своем сеансе, чтобы потом проверить его.