oauth Office365/Outlook.com Mail without Client Secret for public clients

[omnibrain 18]

We are currently redoing our mail module using ICS because Clever Internet Suite seems to be gone for good and The Office 365 sync components we used got bought out and rolled into a completely different solution.
But because our software is a commercial business software that gets used by various end users I registered a "public client" (for "Multiple Organizations") for usage with the "Real O365 Mail for companies and schools", not personal accounts.

 

But the ICS components need a Client_Secret (there are hardcoded checks) but if you send one, you won't get a token:

{"error":"invalid_client","error_description":"AADSTS700025: Client is public so neither 'client_assertion' nor 'client_secret' should be presented. Trace ID: 4b38379d-3e12-485c-aff2-e0f450495800 Correlation ID: ad9abfcf-dac7-461f-a58d-b73136e07ae2 Timestamp: 2025-03-27 20:24:31Z","error_codes":[700025],"timestamp":"2025-03-27 20:24:31Z","trace_id":"4b38379d-3e12-485c-aff2-e0f450495800","correlation_id":"ad9abfcf-dac7-461f-a58d-b73136e07ae2"}

I patched out the check of

if (FClientId = '') or (FClientSecret = '') then begin

it seems I got a valid token, but I'm not sure what else broke, because there definitely seems to be code that still attempts to send an empty client_secret with requests.

[Angus Robertson 625]

Sorry, no quick answer, a public client seems the opposite of the OAuth2 concepts.  My Azure credentials are currently expired or dead, so no recent testing, but I'll look into this next week.

 

Angus

 

[omnibrain 18]

25 minutes ago, Angus Robertson said:

Sorry, no quick answer, a public client seems the opposite of the OAuth2 concepts.  My Azure credentials are currently expired or dead, so no recent testing, but I'll look into this next week.

If you want to read more: https://learn.microsoft.com/en-us/entra/identity-platform/msal-client-applications

 

But I think it should be enough to know that there are client types, that are only identified by ID but must not send a secret.
The user of course still has to enter his credentials into the browser to authenticate, the client sends his ID, so the auth website can show "You are trying to give App XYZ access". Of course that's easy to impersonate, but that's what signed executables are for...
It's all horribly complicated.

[Angus Robertson 625]

So effectively supporting a public ClientId requires the ClientSecret to be specified before GetToken, GrantAuthToken, etc?  Have you tried changing ClientSecret immediately before these methods?  I'm not doing any development for a few days, busy with something else.

 

Angus

 

[omnibrain 18]

2 hours ago, Angus Robertson said:

So effectively supporting a public ClientId requires the ClientSecret to be specified before GetToken, GrantAuthToken, etc?  Have you tried changing ClientSecret immediately before these methods?  I'm not doing any development for a few days, busy with something else.

No, a public client doesn't have a ClientSecret. Only an ID and is created in Azure Entra ID (formerly know as Azure Active Directory) as Multiple organizations type

Like I said, just commenting out the checks if there is a secret and submitting and setting an empty one seems to work. But I'm not deep enough in the component or the OAuth flow to know if something else breaks. It was too late to do further tests. I guess I will know next week.
Take your time, but it would be nice, if you could take a look, when you are back at developing, so we don't have to patch ISC on our end.
If we gather further information I will post here.

[Angus Robertson 625]

If you can privately email the 'public' ClientId for next week, that will save a lot of time setting up Azure, which is always a nightmare. 

 

Angus

 

[omnibrain 18]

My colleague got it work mostly, by ad-hoc patching out every occurance of the ClientSecret, but of course that's not a clean solution, so I appreciate you looking into it. I will send you something to the Delphi@ email from the credit section
 

[Angus Robertson 625]

A new TOAuthOption type of OAopAuthNoCliSecret should fix it.

 

Angus