Handling authorization when testing against API

[goldbergyoni]

@jhenaoz @Thormod @mikicho

I picked this topic as my first challenge. Before I code anything, I'd like to hear your thoughts 🔥

The challenge:

• API is accessible only for the authorized user
• The auth module is outside the scope of the tests, it might even be a 3rd party service
• Performing real-login demands adding a real user to the auth system (which might be outside the scope of the test or the Microservice we approach)
• Log-in in every test might be slow as it demands one more HTTP request per test
• As always, we wish to change/mock as few code as possible
• Login should work also against a remote environment where stubbing is not possible (courtesy of @mikicho )

Solutions (not all of them are good, just stating the options):

• Stub the auth function/module/middleware and instruct it to authorize the request
• Intercept the network call to the users/auth service and trick it to respond with a positive result
• Place a back-door, if config.allowUnAuthorizedRequests then allow requests to be handled without a token
• If it's a monolith, seed a real user, log-in once, store and reuse the token across all requests
• Other?

[mikicho]

• What about testing against real envs with the same suite? IMO the tests should be able to mingle between envs easily. (also for CI/CD)
• In the case your service is behind a3rd party gateway service, you can mock the header.

[goldbergyoni]

What about testing against real envs with the same suite? IMO the tests should be able to mingle between envs easily. (also for CI/CD)

That's a great feature 🔥🚀 which is not necessarily related to auth. I guess it's feasible for some of the tests (black-box tests) as those who are utilizing test doubles or alter the config (grey-box tests) won't be able to run against remote env. How can we separate between the two? Probably need to tag the black-box tests + make the URL inference dynamic, not always work against localhost rather make this configurable. I would also add this to our features list in the home page.

In the case your service is behind a3rd party gateway service, you can mock the header.

Not sure I followed, could you clarify?

[mikicho]

@goldbergyoni For example, if you use Apigee, the authorization step happens before the request get to the service, so you can just send a mocked Authorization header

[goldbergyoni]

@mikicho What is a mocked auth header? I guess you refer to API gateways which accept a valid token

I'm asking to ensure I don't miss a bit

[mikicho]

@goldbergyoni mocked auth header is jwt for example. If you sever doesn't verify it (because this is happening before the request hit your sever) you can send whatever value you want