Load testing a React single-page application that uses auth0-react

Get Help
,
1

I’ve looked at other load-testing related threads here but I haven’t found one that matches my case.

I have a React SPA application that uses auth0-react. I would like to perform browser-based load tests using a framework like Playwright.

In certain scenarios, I can use a mock like mock-oauth2-server to handle authentication. That isn’t a problem.

I would also like to load test some environments where using the mock oauth2 server is not an option, and we have to go through the actual Auth0 service. But I don’t want to perform the full login flow for each browser. I’m not sure how to avoid that.

One possiblity would be to get an access token using the Client Credentials Flow (instead of the Authorization Code Flow) before starting the load test, and somehow inject it in each browser that is spawned during the load test.

My question is: is there a way to make auth0-react to use this preexisting access token, or should I include some conditional logic in my SPA to behave differently when it detects the “injected” token?

3

Hi @danidiaz.art

Welcome to the Auth0 Community!

Regarding your implementation for load-testing, using the Client Credentials Flow would not be recommended since it covers Machine-to-Machine applications and not actual user authentication.

My suggestion would be to use the Resource Owner Password Flow in order to retrieve the tokens of the user an basically initiate an SSO session for your application. You would need to first enable the Password grant for your application within the Auth0 Dashboard. This can be found under Applications → Applications → Your_Application → Advanced Settings → Grants → Password. The request would look something like:

const response = await fetch(`https://${AUTH0_DOMAIN}/oauth/token`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        grant_type: 'password',
        username: 'testuser@example.com', 
        password: 'TEST_USER_PASSWORD',   
        client_id: AUTH0_CLIENT_ID,
        client_secret: AUTH0_CLIENT-SECRET
        scope: 'openid profile email offline_access',
      }),
    });

Once you have extracted the id_token from the response, you should be able to add it to an /authorize call as a hint in order to create the Auth0 session and then redirect to your page. The /authorize call would look like this:

https://nik-sp.us.auth0.com/authorize?response_type=token&client_id={{CLIENT_ID}}
&redirect_uri={{APPLICATION_URL}}&prompt=none
&id_token_hint={{USER_ID_TOKEN}}

Once you navigate to your page, it should be an authenticated page and able to test any protected API routes or other functionalities.

Let me know if the suggestion above is useful regarding the matter or if you have any other questions.

Kind Regards,
Nik

4

Hi @nik.baleca, thanks for your answer.

A further question: if I understand correctly, the approach involving the Resource Owner Password Flow wouldn’t prevent repeatedly contacting Auth0’s own service from each headless browser.

It would, however, avoid the further indirection of having to authenticate with Google from each headless browser (I’m assuming the case in which Auth0 is configured to rely on Google Auth).

Is that impression correct?

Also, about:

Regarding your implementation for load-testing, using the Client Credentials Flow would not be recommended since it covers Machine-to-Machine applications and not actual user authentication.

Our application already uses machine-to-machine users to access the underlying application API, and we could add more for the purposes of load testing. But maybe there are inherent impediments in using (in the special context of testing) authorization tokens obtained using the Client Credentials Flow in an SPA?

5

Hi again!

That would be correct, basically, the ROPG flow would be a trade-off in this matter.
With ROPG, you are still making two primary API calls to Auth0 service for each virtual session:

  • A call to /oauth/token to exchange credentials for tokens.
  • A call to /authorize to use the id_token to establish an SSO cookie-based session.

This approach would help you bypass the need for any user interaction while you are performing the load tests with federated IdPs (such as Google) since they are often loaded with interactive forms, captchas, MFA prompts. This would provide you with a direct and automated way to test the authentication flow with Auth0 users which would not be possible with federated IdPs.

Our application already uses machine-to-machine users to access the underlying application API, and we could add more for the purposes of load testing. But maybe there are inherent impediments in using (in the special context of testing) authorization tokens obtained using the Client Credentials Flow in an SPA?

To answer shortly, yes. If I a not mistaken, this would be a reflection of how the SDK is designed to work since the core issue is that an M2M token and a user token represent two entirely different entities within Auth0. If you are looking to load-test the authentication flow, the ROPG would be a better recommendation since the a React SPA application would be focused on human user session where the SDK takes care of managing their identity, sessions and resource access on their behalf.

However, for the purpose of your tests, you can have M2M client initiated during the load-tests so that you can test specific user interactions within your application (ex: initiate a transaction, accessing specific restricted resources).

To summarize, you would need a user session created with ROPG whose session is then “injected” via the /authorize call in order for the M2M application to perform actions on their behalf if needed.

If I can help with anything else, let me know!

Kind Regards,
Nik

1 Like
6

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.