Request for Bearer Token support in httpAuth()

[Thunderforge]

Per the user guide:

Currently httpAuth() only provides basicAuth method. If you need other scenarios, please let us know by creating an issue in the repository.

The scenario I need is Bearer Token, so I'm posting an issue in the repository to let you know I need it 😀

[rabelenda]

Great! thank you for asking for this! :)

Since this is not something the JMeter Auth Manager already supports (I guess due to httpClient library api limitations), which got my attention the first time I tried this, we would need to implement some custom solution if we want to simplify this over what JMeter already provides.

The usual way to solve this in JMeter is adding http headers manually, which you can do with DSL with httpHeaders element or header method in httSampler.

I will open for discussion how can we further simplify this, so anyone can take part of the decision.

Some options

httpAuth.bearerAuth

I think bearer token, taking into consideration already supported basic auth, could be expressed with something like this:

httpAuth()
  .bearerAuth("https://myservice.com", "myToken")

Implementation options

hidden HTTP Header Manager

DSL adds a HTTP header manager setting the token

• Con: Has the problem that it would send the token with every http sampler, potentially leaking the token to undesired sites (other samplers to other domains, or embedded resources). In other words, the url as first parameter would have no usage :(.
  • It may even make some requests fail: sites not expecting the authentication may reject the request
• Pro: Authentication centralized in one place. No need to remember that some are set with httpHeaders and some are set with httpAuth.
• Pro: Users wouldn't need to remember the name of the proper header (Authorization) and Token prefix in value.

JSR223 pre & post processor

DSL adds JSR223 pre processor which checks sampler URL and adds header manager (or modifies existing one) to sampler on the fly.

• Con: More elements in test plan than previous approach, and more complexity in test plan
• Pro: Avoids leaking token to samplers that should not use the token
• Con: Still leaks token to embedded resources

Extend JMeter & httpClient Authentication

• Con: Quite complex to implement and may even require modifying existing libraries APIs and classes. So in general I think we should avoid this.
• Con: would require custom logic to properly work with remote engines (BlazeMeter, OctoPerf, Distributed, etc)
• Pro: would avoid most of token leaks.

httpHeaders & httpSampler new method

Just add an auxiliary method to existing httpHeaders & sampler which allows to easily set auth token. Eg:

httpHeaders()
  .bearerAuth("myToken")

• Pro: Simple to implement and easy to map to JMeter usage
• Con: Users need to remember that authentication headers are set one way or another depending on the mechanism used (eg: httpAuth.basicAuth vs httHeaders.authBearerToken)
• Con: This is still prone to misconfiguration or issues due to Token being sent to embedded resources or other samplers.

Not implement new logic

Just keep with existing JMeter option of using httpHeaders.header("Authorization", "Bearer TOKEN")

• Pro: No code changes required in DSL.
• Con: Does not simplify in any way users to set bearer token.
• Con: Prone to same problem already described about token leaks.

Anyone has any thoughts? Any other ideas? Comments? Pros & Cons?

[Thunderforge]

My personal preferred solution would be some sort of .bearerAuth() method that works like the existing basicAuth() method. I'm not understanding the distinction between:

httpAuth()
  .bearerAuth("https://myservice.com", "myToken")

and

httpHeaders()
  .bearerAuth("myToken")

Is it just a matter of scope limitation where in the former the token is limited to https://myservice.com? If so, that looks like enhanced functionality beyond what basicAuth() currently does.

[rabelenda]

Hello, thank you for taking the time to review the ideas and give some feedback.

Yes, the difference between the first one and the second one, is that the first one should apply only to urls that start with given URL. Why do you say it looks like enhanced functionality beyond what basicAuth() currently does? basicAuth() requires you too to set a URL which in fact is used to control when should it add the basic header (according to request URL), and when it shouldn't.

If we think the first one should be preferred, so far I think the best approach, considering pros/cons is adding jsr223Pre & post processors with a note on the DSL method stating that downloadEmbeddedResources() should be avoided when using httpAuth().bearerAuth().

Any thoughts @kirillyu , @andy-tarr , or anyone else?

[kirillyu]

I tend to agree with you on this.

[Thunderforge]

Why do you say it looks like enhanced functionality beyond what basicAuth() currently does?

I think that I was mixing basicAuth() up with httpHeaders() (the way I have been doing it bearer tokens), which does not require a URL. Consistency with the other authentication methods is fine with me.