Oauth 2 - params ordering and signature integrity

Question

I have two questions:

Q1: Why does OAuth2 require params to be ordered and encoded (for 2-legged)?

All it has to worry about is the matching signature in both the end for the given data(query string).

We can just check the signature generated using the query string.(e.g ?a=1&b=2). Since the signature is generated based on the secret key which is known only to the client and provider, we can only consider the query string without any ordering/encoding.

So, what's the advantage in doing ordering/encoding and then creating the signature?

Q2: How can this signature save me from man-in-the middle attack?

If I have to make a request like this to my server from a client:

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

Now the token XYZ will be always same, so a hacker could keep posting the same request to increase points. Since the generated token from the given appId is the same, the server will allow this. How is this case handled?

Answer 1

Q1: Ordering the query parameters brings sanity to the HMAC.

Let's say you have two parameters: 'pointsToAdd' and 'appId'. Using the query string pointsToAdd=X&appID=y creates a different HMAC to appID=y&pointsToAdd=X. Because both you and the server need to generate the same HMAC to verify the requests having unordered query parmeters plain fails.

Q2: This saves you from an attack because only you and the server know how to sign your request.

You have a secret key, and only you and the server knows it. This key signs the request. If the HMAC doesn't match according to this secret key, the request fails.

Because all parameters have been used to create the HMAC the request is secure from MITM attacks — a hacker can't change, add or delete any query parameters, or the server will produce a different HMAC when it attempts to authorise and the request fails.