I wrote a custom Processor heavily based on OAuth2ClientConfigurer.
But if I was to incorporate it into the OAuth2ClientConfigurer it would look
something like the following. (With this code replacing OAuth2ClientConfigurer
.getAccessTokenResponse()). Untested and not production ready arch/code or
anything – but you’ll get the idea.
private JsonObject getAccessTokenResponse(HttpClient httpClient) throws
IOException {
final HttpPost httpPost =
getTokenRequestBuilder().buildRequest();
AtomicReference<JsonObject> result = new AtomicReference<>();
httpClient.execute(httpPost, response -> {
try {
String responseString =
EntityUtils.toString(response.getEntity());
if (response.getCode() == 200) {
result.set((JsonObject) Jsoner.deserialize(responseString));
} else {
throw new HttpException(
"Received error response from token request with
Status Code: " + response.getCode());
}
} catch (DeserializationException e) {
throw new HttpException("Something went wrong when reading
token request response", e);
}
return null;
});
return result.get();
}
private TokenRequestBuilder getTokenRequestBuilder() {
//better factory required…
if(tokenEndpoint.contains("login.microsoftonline.com")) {
return new MicrosoftTokenRequestBuilder();
}else {
return new TokenRequestBuilder();
}
}
//Probably wouldn’t want inner classes – especially if you’d support custom
implementations. Inner classes currently using out class variable – would have
to be reworked.
private class TokenRequestBuilder {
public HttpPost buildRequest() {
// the existing code becomes the default
String bodyStr = "grant_type=client_credentials";
String url = tokenEndpoint;
if (scope != null) {
String sep = "?";
if (url.contains("?")) {
sep = "&";
}
url = url + sep + "scope=" + scope;
}
final HttpPost httpPost = new HttpPost(url);
httpPost.addHeader(HttpHeaders.AUTHORIZATION,
HttpCredentialsHelper.generateBasicAuthHeader(clientId, clientSecret));
httpPost.setEntity(new StringEntity(bodyStr,
ContentType.APPLICATION_FORM_URLENCODED));
return httpPost;
}
}
private class MicrosoftTokenRequestBuilder extends TokenRequestBuilder{
public HttpPost buildRequest() {
String sep = "&";
String bodyStr = "client_id=" + clientId;
bodyStr = bodyStr + sep + "client_secret=" +
URLEncoder.encode(clientSecret, StandardCharsets.UTF_8);
bodyStr = bodyStr + sep +
"grant_type=client_credentials";
if(scope != null) {
bodyStr = bodyStr + sep +
"scope=" + URLEncoder.encode(scope, StandardCharsets.UTF_8);
}
final HttpPost httpPost = new
HttpPost(tokenEndpoint);
httpPost.addHeader(HttpHeaders.AUTHORIZATION,
HttpCredentialsHelper.generateBasicAuthHeader(clientId, clientSecret));
httpPost.setEntity(new StringEntity(bodyStr,
ContentType.APPLICATION_FORM_URLENCODED));
return httpPost;
}
}
[cid:guild_group_box_1d412af1-affb-4c07-9f3a-296134fb000c.png]<https://www.guildgroup.com.au/><https://www.guildgroup.com.au/>
Andy Gilette
Solutions Architect - Software Engineer
Level 1, 132 Leichhardt Street, Spring Hill, QLD 4000
p: +61 3 7000 0405
w: guildgroup.com.au<https://www.guildgroup.com.au>
[cid:thrivetogether-blue_4c72fa74-1bd9-4732-bb06-cf4ebbd58bac.png]
We work flexibly at Guild. I'm sending this message at a time that suits me.
Please feel comfortable knowing that I don't expect you to read, respond to or
action it outside of regular working hours.
In the spirit of reconciliation, Guild Group acknowledges the Traditional
Custodians of Country throughout Australia and their connections to land, sea,
and community. We pay our respect to their Elders past and present and extend
that respect to all Aboriginal and Torres Strait Islander peoples today.
________________________________
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and delete this e-mail from your system. Any
unauthorised copying, disclosure, dissemination or distribution of the material
in this e-mail is strictly forbidden. The sender, as well as Guild Group
Holdings and any of its related companies do not guarantee the integrity of any
e-mails or attached files. E-mail transmission cannot be guaranteed to be
secure or error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any such problems in the contents of this message
which arise as a result of e-mail transmissions.
From: Claus Ibsen <claus.ib...@gmail.com>
Sent: Friday, 13 June 2025 5:27 AM
To: users@camel.apache.org
Subject: Re: Http Component - Oauth2 not working Microsoft Authorization servers
Hi
So did you implement a solution for this?
If MS Authentication Server has this requirement, then it may be nice to
have some kind of option in camel-http, you can set that then adjusts Camel
to MS style.
It can be some kind of vendor string so in the future there can be other
implementations if they are also "special".
On Tue, Jun 10, 2025 at 3:08 AM Andy Gilette
<agile...@guildgroup.com.au<mailto:agile...@guildgroup.com.au>>
wrote:
> Hi all,
>
> I am looking for some advice regarding implementing oauth2 for the http
> component when authentication with Microsoft authentication servers. Many
> of our authorisations go through this so I’d prefer a more reusable
> solution.
>
> First up, you might ask why can’t I just use the oauth2 parameters
> provided by the http component?
>
>
>
> Because Microsoft servers expect a token request in the following format.
>
> POST /{tenant}/oauth2/v2.0/token HTTP/1.1 //Line breaks for
> clarity
>
> Host:
> http://login.microsoftonline.com:443<http://login.microsoftonline.com:443>
>
> Content-Type: application/x-www-form-urlencoded
>
>
>
> client_id=<client id>
>
> &scope=<some scope>
>
> &client_secret=<client secret>
>
> &grant_type=client_credentials
>
> While camel builds a token request in the following format.
>
> POST /token HTTP/1.1
>
> Host: server.example.com
>
> Authorization: Basic <base 64 encoded "client id:client secret">
>
> Content-Type: application/x-www-form-urlencoded
>
>
>
> grant_type=client_credentials
>
> scope=<some scope>
>
>
>
> Now, you could argue Microsoft isn’t meeting the standard (rfc6749) or
> that camel is being too strict on the standard(In my reading, I doesn’t
> seem to precisely specify how to pass in the clientid and secret, or even
> that you need clientid and secret to conform to the standard. The only
> place it mentions the Authorization header is in an example, and an example
> to me means one possible way of implementing the standard – not the only
> way).
>
> Regardless, I’d like some suggests around the best way to implement this.
>
> Some possibilities…
>
>
>
> 1. Set some known variables for clientid, secret etc etc, and use
> enrich() to make my own call to the authentication server
> 2. Implement my own HttpClientConfigurer extending
> OAuth2ClientConfigurer.
> 1. This isn’t quite so straightforward as I’d like because I can’t
> extend the existing OAuth2ClientConfigurer. It is created a runtime, rather
> than route configuration. It takes clientid etc in the constructor, which
> are only available at runtime, not the normal place where you would
> configure a custom HttpClientConfigurer. In other words – Unlike other
> HttpClientConfigurer, the OAuth2ClientConfigurer is one object per http
> call, rather then one globally reused object. To inject an extension of
> OAuth2ClientConfigurer, that works in the same way, I’d need to create a
> new HttpComponent implementation(also difficult to extend the existing
> implementation due to private methods.)
> 3. Implement my own HttpClientConfigurer that doesn’ t extending
> OAuth2ClientConfigurer – and implement my own custom oauth2 parameters that
> don’t cross over with the standard ones in order to avoid invoking the
> out-of-the-box OAuth2ClientConfigurer.
> 4. Contribute an extendable OAuth2ClientConfigurer, which would
> possible need some degree of redesign of this portion of the HttpComponent.
>
>
>
> Or any other recommendations.
>
> I guess, I’m leaning towards the enrich – as the quickest way to implement
> – it just hurts to not use the oauth2 features that come out-of-the-box.
>
>
>
> Thanks in advance.
>
> Andy
>
>
>
>
>
>
>
>
> <https://www.guildgroup.com.au/<https://www.guildgroup.com.au>>
> <https://www.guildgroup.com.au/<https://www.guildgroup.com.au/>>
>
> *Andy Gilette *
> Solutions Architect - Software Engineer
>
> Level 1, 132 Leichhardt Street, Spring Hill, QLD 4000
> *p*: +61 3 7000 0405
> *w: *guildgroup.com.au
> <https://www.guildgroup.com.au<https://www.guildgroup.com.au>>
>
> We work flexibly at Guild. I'm sending this message at a time that suits
> me. Please feel comfortable knowing that I don't expect you to read,
> respond to or action it outside of regular working hours.
>
> In the spirit of reconciliation, Guild Group acknowledges the Traditional
> Custodians of Country throughout Australia and their connections to land,
> sea, and community. We pay our respect to their Elders past and present and
> extend that respect to all Aboriginal and Torres Strait Islander peoples
> today.
>
> ------------------------------
>
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and delete this e-mail from your
> system. Any unauthorised copying, disclosure, dissemination or distribution
> of the material in this e-mail is strictly forbidden. The sender, as well
> as Guild Group Holdings and any of its related companies do not guarantee
> the integrity of any e-mails or attached files. E-mail transmission cannot
> be guaranteed to be secure or error-free as information could be
> intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
> contain viruses. The sender therefore does not accept liability for any
> such problems in the contents of this message which arise as a result of
> e-mail transmissions.
>
--
Claus Ibsen
