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>
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: 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/>
>
> *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>
>
> 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
