BlazeMeter Pro及JMeter中OAuth2.0 Gmail登录认证负载测试脚本录制与配置指导请求

Hey there, I’ve worked through exactly this scenario before—recording OAuth2 flows with third-party providers like Gmail almost never works smoothly because of browser-based redirects and dynamic session data. Instead of relying on the recorded login steps, let’s replace that with a direct token-based authentication flow using the parameters you already have. Here’s how to set it up:

Step 1: Replace Recorded Login with a Token Request #

The recorded Gmail login page interactions are meant for human users, not load testing. We’ll skip all that and use your refresh_token to fetch a valid access_token directly from Google’s OAuth endpoint.

• Add an HTTP Request sampler to your JMeter test plan:
  • Set Method to POST
  • Set URL to https://oauth2.googleapis.com/token
  • Go to the Parameters tab and add these key-value pairs (use your actual values):
    • client_id: Your client ID
    • client_secret: Your client secret
    • refresh_token: Your refresh token
    • grant_type: refresh_token

Step 2: Extract the Access Token for Reuse #

Once we get the token response, we need to pull out the access_token and store it in a variable so subsequent requests can use it.

• Add a JSON Extractor as a child of the token request sampler:
  • Set Reference Name to access_token (this is the variable name we’ll use later)
  • Set JSON Path Expression to $.access_token (this targets the access token in Google’s JSON response)
  • Set Match No. to 1 (we just need the first match)

Step 3: Authenticate Subsequent Requests #

Your system almost certainly uses a Bearer Token for authorization. We’ll add a header to all future requests to carry the valid token.

• Add an HTTP Header Manager to your test plan (or to the thread group containing your main application requests):
  • Add a new header with:
    • Name: Authorization
    • Value: Bearer ${access_token}
  • This header will automatically inject the access token we extracted into every request that uses this manager.

Step 4: Handle Multi-User Scenarios #

If you’re testing with multiple users, each will need their own refresh_token (client_id and client_secret might be shared across users, depending on your setup).

• Create a CSV file with columns for each user’s credentials, e.g.:

  client_id,client_secret,refresh_token
  your-client-id,your-client-secret,user1-refresh-token
  your-client-id,your-client-secret,user2-refresh-token
  

• Add a CSV Data Set Config to your thread group:
  • Set Filename to the path of your CSV file
  • Set Variable Names to client_id,client_secret,refresh_token (matching your CSV columns)
• Update the token request sampler’s parameters to use these variables instead of hardcoded values (e.g., ${client_id} instead of your static ID)

Step 5: Validate the Flow #

• First run a single-thread test to verify:
  1. The token request returns a 200 OK status and a valid access_token in the response
  2. Subsequent requests to your system return successful responses (200 OK, and the expected UI content or API data)
• Once that works, scale up to multiple threads to test the multi-user scenario.

Why This Works Better Than Recording #

Recording the Gmail login flow fails because:

• JMeter can’t reliably capture all browser-specific session data (like cookies or dynamic redirect parameters) during the OAuth redirect
• Simulating browser login in load tests is inefficient and doesn’t reflect how actual clients would authenticate (they’d use tokens directly)
• Refresh tokens are designed to be reused to get new access tokens without re-authenticating via the browser

内容的提问来源于stack exchange，提问作者ankit dasani