Automated API testing of OAuth2/OpenID Connect protected API

Question

I'm looking into a new project that we are planning on doing API first, so that we can then implement web- and native- apps on top of, plus allow for third party integration. All fairly standard so far.

We also want to have a full suite of automated tests for the API, both to ensure that it works without regressions, and to ensure it meets the requirements. Again, fairly standard, but because we are testing the API we will be using an in-code HTTP client and not a web browser.

We have been looking at oauth2/OpenID Connect to facilitate authentication and authorisation for the API - basically so clients can authenticate, get an access token and then use that to access all of the API resources.

What I'm struggling to work out is a good way of getting the automated tests to work with the oauth2 part to be able to actually call the API. The first thought was to use the "client_credentials" or the "password" grant types, which both seem like they would work for what we want, but they're not covered in the OpenID Connect spec at all, and of course the"password" one at least it's generally not considered a good idea anyway.

Is this the best way to achieve this or are there other best practices for this kind of situation that can be used with the other flows, but without a web browser?

Edit: after (much) more reading, I have a new plan. Running tests entirely offline, using a separate deployment against a separate database and seeding data directly into the database before the tests run, and then using the standard OpenID Connect flows, but with:

• A client that is marked in the database as for testing purposes. This is an important bit, and is only possible if the client can be registered direct into the database without going through business logic.
• prompt=none
• login_hint=the user name to get an access token for
• scope containing "testing"

The system can then detect this combination of facts, and auto authenticate the provided username without needing to go through a browser.

Does this seem reasonable? Or is there a better way?

Answer 1

Since you're looking to test the API, it should not matter how you got the access_token, through the browser or through some other way. So there are (at least) two solutions:

1. That other way could be the client_credentials grant. You will have to make the Authorization Server return an access_token that resembles an access_token that would be returned for a user in an OpenID Connect flow through the browser but depending on your AS implementation that should be doable.

2. Bootstrap your client using a regular OpenID Connect browser flow to generate a refresh_token alongside of an access_token and store both tokens with your test client together with the client_id and client_secret at configuration time. Your test client can then access the APIs until the access token expires and subsequently get a new access_token through the refresh_token grant type (leveraging the client_id and client_secret).

OpenID Connect itself, the user authentication and the id_token are irrelevant to your APIs that should care about the access_token only.