I have a web application where users must authenticate with a 3rd-party OAuth 2.0 service in order to do what they need to do in the app. On initial registration/login, they will connect with the service and my backend will get their access tokens and refresh tokens and keep those fresh for the duration of their user existing in our system (unless they are revoked).

Since the majority of my application needs a valid Oauth 2.0 token with this service to properly function, I also need a valid token in my tests (both local and on my CI/CD - currently on AWS).

What I am looking for is a "proper" way to both get and store these tokens non-interactively (since during testing, the user would have to open the browser, connect to the service, then be redirected back to my app). I see a few ways to do this; however, I do not see anything out there right now that is off-the-shelf and I could use immediately. I am looking for options if people are aware.

Possible "ways" of doing this that I can see:

  1. Use something like Selenium to automate the login and OAuth 2.0 connection flow with a real browser as a fixture that will be used by other tests in the test suite. Not sure how well this would work on something like AWS CodeBuild without using a headless browser.
  2. Build a new HTTPS application, hosted in AWS or elsewhere, where you can configure OAuth 2.0 connections with a sandbox server on the 3rd-party service, and the server, much like my actual app, will keep the tokens fresh using background tasks. Then, the idea would be to provide ANOTHER set of credentials to this server that I could fetch in my local tests and in CI/CD to get the OAuth 2.0 access token for a specific connected user that has been done once manually in this new application.
  3. Some way of interactively connecting to the OAuth 2.0 server as part of the local test suite (I am using Python, Flask, and PyTest). I am not sure how/if this could work on AWS.
  4. Finally, take the most recent tokens I have from a local version of my app, and always be changing them out in the environment variables of both the AWS CI/CD and my local tests. Extremely non-optimal.

I thought that something out there to do this would exist, given how often now 3rd-party services do not provide a key and secret like OAuth 1.0 where no interaction is required.

1 Answer 1


You're expected to test your application, not the third-party service; this means that the tests you run during continuous integration should cover your application only.

Imagine that the third-party service has problems: why, then, you would fail your build? Your build should still pass, and it's up to the production monitoring tools to highlight that there is a problem with the third-party service.

This means that you have two solutions:

  1. You can create your own OAuth 2.0 provider that you would host locally.

    The benefit is that you can do with it whatever you want, such as creating as much test accounts as you like, and running lots of tests, and all sorts of tests, including the penetration tests. If you do that with a real OAuth 2.0 provider, unless you have a specific contract with them which describes those tests, you're at risk that the provider will simply block you.

    The drawback is that it may not be that easy to create a compliant provider. I suppose that there are libraries which do that for the framework of your choice, but if not, you may not want to go this way.

  2. You just fake your application by injecting, during the tests, a class which feeds the application with the test tokens.

    The benefit is that it's easy to do, and possibly you have one already for the unit tests.

    The drawback is that you won't test the actual interface of your application with the OAuth 2.0 provider.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.