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

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

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

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

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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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