Отзывы и пожелания. Wargaming Public API

armor_kiev (28 Окт 2013 - 15:49) писал: Попробовал авторизацию через API (пока пользуюсь классическими методами OpenID без API).
По-моему есть очевидные дыры в безопасности.
Предположим, что я делаю авторизацию через API в лоб (а для теста функционала так и сделал).
Что возвращает сервер авторизации? Примерно такой URL:
http:// мой-сайт.ру/login?&status=ok&access_token=2dba994dec1901b296a01709fcdf332d9d925813&nickname=armor_kiev&account_id=94868&expires_at=1384171147
Итак, предположим, что я все сделал тупо в лоб. Что мешает злоумышленнику попытаться войти на мой сайт этой же самой ссылкой с другими nickname и account_id?
Ничего не помешает, ведь статус "ок" :) Проверять реферер? Можно подделать.
access_token? Что это и зачем? Оно тупо идет в открытом виде и я на своей стороне не знаю какой именно должен придти access_token, подделан он или подставлен перехваченный злоумышленником.
Т.е. для поддержания безопасности на минимальном уровне необходимо делать неочевидные и незадокументированные вещи:
1) сохранять в сессии информацию о факте отправки запроса на авторизацию;
2) создавать свой уникальный секретный ключ, который на текущий момент использовать пока только параметром в redirect_uri (например: &skey=dfgsfw4y76yh6uyeth) - по получению ответа сравнивать со значением в сессии и сбрасывать, повторный прием уже недопустим.
3) Может что еще - подскажите кому не жалко.
Безопасность в данном случае важнейший элемент, поэтому
Предлагаю
1) к описанию протокола добавить четкие пошаговые инструкции и примеры кода, которые показывали бы методы решения (обхода) описанных выше проблем;
2) в параметры запроса на вход добавить обязательный параметр: уникальный секретный ключ, который генерируется на стороне запрашивающего сервера и отправляться может исключительно get или post запросом с сервера, а не посредством ссылки или формы в браузере клиента. Ключ возвращать в ответе сервера авторизации. С этим разобрались - решается проверкой токена через auth/prolongate.