Oauth 2 - порядок следования параметров и целостность подписи

Question

У меня два вопроса:

Q1: Почему OAuth2 требует упорядочения и кодирования параметров (для двухсторонних)?

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

Мы можем просто проверить подпись, сгенерированную с помощью строки запроса (например,? A = 1 & b = 2). Поскольку подпись генерируется на основе секретного ключа, который известен только клиенту и поставщику, мы можем рассматривать только строку запроса без упорядочивания / кодирования.

Итак, в чем преимущество при заказе / кодировании и создании подписи?

Q2: Как эта подпись может спасти меня от атаки "человек посередине"?

Если мне нужно отправить запрос на сервер на мой сервер:

increaseUserPoints?userId=1&pointsToAdd=5&appId=x&token=XYZ

Теперь токен XYZ будет всегда одинаковым, поэтому хакер может продолжать публиковать один и тот же запрос на увеличение points. Поскольку сгенерированный токен из данного appId совпадает, сервер разрешит это. Как обрабатывается этот случай?

Answer 1

Q1: упорядочение параметров запроса приносит здравомыслие в HMAC.

Допустим, у вас есть два параметра: 'pointsToAdd' и 'appId'. Использование строки запроса pointsToAdd=X&appID=y создает HMAC, отличный от appID=y&pointsToAdd=X. Поскольку и вам, и серверу необходимо сгенерировать один и тот же HMAC, чтобы проверить, что запросы с неупорядоченными параметрами запросов просто не выполняются.

Q2: Это спасает вас от атаки, потому что только вы и сервер знаете, как подписать ваш запрос.

У вас есть секретный ключ, и его знают только вы и сервер. Этот ключ подписывает запрос. Если HMAC не соответствует этому секретному ключу, запрос не выполняется.

Поскольку все параметры были использованы для создания HMAC, запрос защищен от атак MITM - хакер не может изменить, добавить или удалить любые параметры запроса, или сервер выдаст другой HMAC, когда попытается авторизоваться, и запрос не выполнен.