Hi All, Yes, this is one way of getting the Auth token in order to pass it into the http component. It should work. I ultimately have done something similar- just with raw HTTP calls and custom token cache rather than MSAL4J. Thanks for the reminder that I could use the MSAL4J jars, I’d forgotten about these because we couldn’t use them in previous projects due to dependency version clashes. If I get some time I might look at switching to MSAL4J as it would simplify my code and probably be an improvement on my custom token cache. Still, it would be great if the http component itself could handle the Microsoft Authorization server request formats at some point in future. Regards Andy
[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: Dipak Rai <fullstackdipak...@gmail.com> Sent: Friday, 13 June 2025 1:37 PM To: users@camel.apache.org; Andy Gilette <agile...@guildgroup.com.au>; claus.ib...@gmail.com Subject: Re: Http Component - Oauth2 not working Microsoft Authorization servers Hi Andy, Claus, Sorry that I couldn't reply earlier. But MS Server expecting a 'token' is not a problem. I am connecting to MS Server via token itself in the below way successfully. I hope it helps: //import the msal4j library as a pom dependency <code-snippet-starts-here> String AUTHORITY = "https://login.microsoftonline.com/<https://login.microsoftonline.com/>" +"your-oAuth2-tenantID-here"+"/v2.0"; String SCOPES = "https://outlook.office365.com/.default<https://outlook.office365.com/.default>"; try { ConfidentialClientApplication app = ConfidentialClientApplication .builder("your-oauth2-client-id-here"), ClientCredentialFactory.createFromSecret("your-oauth2-client-secret-here")) .authority(AUTHORITY) .build(); ClientCredentialParameters clientCredentialParam = ClientCredentialParameters .builder(Collections.singleton(SCOPES)) .build(); CompletableFuture<IAuthenticationResult> future = app.acquireToken(clientCredentialParam); IAuthenticationResult result = future.get(); return result.accessToken() } catch (Exception e) { return exception; } <code-snippet-ends-here> Regards, Dipak. https://stackoverflow.com/users/3300911/raikumardipak<https://stackoverflow.com/users/3300911/raikumardipak> On Fri, Jun 13, 2025 at 1:02 AM Claus Ibsen <claus.ib...@gmail.com<mailto:claus.ib...@gmail.com>> wrote: 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: 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<http://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<http://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
