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/"; +"your-oAuth2-tenantID-here"+"/v2.0"; String SCOPES = "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 On Fri, Jun 13, 2025 at 1:02 AM Claus Ibsen <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> > 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 >
