Avoid brute force attacks on oAuth authorization server

Question

I've been looking into the oAuth 2 authorization framework for a while now. Yesterday I started wondering how to prevent a brute force attack during the Authorization Code Grant flow (https://www.rfc-editor.org/rfc/rfc6749#section-4.1). To clarify, the flow works as follows:

1. Browser sends a requests for a protected resource on an oAuth 2 client (client.example.com).

2. Browser is redirected to the authorization endpoint on the authorization server:

   GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

with state being some kind of random string generated by the oAuth 2 client

3. Browser logs in on Authorization server

4. When correctly logged in, the browser is redirected back to the redirect-uri with some query parameters

   https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

the state string should be the same as sent by the client, and the token a string generated, by the authorization server.

5. The client verifies whether the state parameter belongs to the session of the user agent (to prevent XSRF) and requests the access token from the authorization server using the code query parameter and basic authentication with the clients credentials:

   POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

It is possible for an attacker to repeat steps 2 and 4 over and over again, without actually logging in to the authorization server:

1. Go to a restricted resource on client.example.com.
2. Parse the state request parameter in the redirect (and store the cookie/session id)
3. Try getting a token for value1 by going to https://client.example.com/cb?code=value1&state=xyz (with cookie/session id received in 1)

Do this again and again for code=value2, code=value3, ...

Nothing stays the same in between two attempts of the attacker, which makes it hard for the authorization server to store a number of attempts and block after a certain number.

However, there is probably a small time window for the attacker to perform the attack, since the code is only valid on the server between steps 4 and 5 in the flow (except if the client crashes somewhere between 4 and 5).

Other then

• having a large code generated by the authorization server
• making the codes available only for a limited amount of time

is there anything else we can do to prevent the described attack?

Answer 1

1. You design the code to be unrealistically guessable.

2. You can also rate limit by IP address.

Then you have a well hardened service. Really just stick with number 1 though. It’s much better than rate limiting.

If you use a cryptographic number generator to create 128 bits of random data, and base 64 encode that, then use that as your code. The probability of guessing that 128 bit string is u likely in the next decade with a bunch of computers working on it full time.