Has anyone tried calling Microsoft Identity Provider or validating against Entra ID in a VFP desktop app — possibly via DotNetBridge? Is it doable? Any tips or references?

I have a desktop app that can do oAuth2 authentication against Entra. It's a bit trickier than a web app because oAuth2 best practice says you mustn't use a WebBrowser form or manage the interaction yourself. You're supposed to spawn a default browser instance and then listen for a response that gets redirected from the browser with an authorization code. Once you have the authorization code you can use wwHTTP or whatever to submit the authorization code and get an access token confirming the user did authenticate and what access rights they have. I got the browser part going with a redirect URL using a local port that won't be used for anything else and doesn't get blocked by Defender, and the rest is straight HTTPS submission. I'll see if I can dig out the code...

Thanks, John. I'm really confused. One site said the OAUTH2 was about Authorization and ENTRA-ID was about Authentification, and they were separate issues and I was mixing them up.

I used to call the windows API

llOK = LogonUser("", C_USERDOMAIN, pcUserId, pcPassword)

and it was simple. I would have loved to just replace that line with a web API call, but I'm not even sure that is possible at this point.

Yeah it's not that simple with Web\Network authentication because it's all async and it requires a Web browser.

• Authentication
  Identifies who you are.

• Authorization
  Determines what you have access to.

Logging in is basically who you are. The rights on what you can do are assigned based on what you have access to.

Just one more thing to widen the moat around the big players fiefdom...

Windows Authentication used to be easy because it was part of the system and the resources you had access to were restricted. With these ideas it's typically Web resources that are restricted so that's a bit different.

oAuth is a pain in the ass because it essentially requires a Web browser (whether a real browser or a hidden browser instance) that can handle the two way handshake and that's where all this complication comes from. As John pointed out hidden browsers can be used, but might raise issues in a security audit. I think you can mitigate some of that by using an approved SDK from a vendor (ie. Microsoft). The Azure SDK automates some of this in the background, but even those tend to be async and not particularly easy to access from FoxPro.

I think the Azure .NET SDK has the endpoints for all of that and you can access this through wwDotnetBridge from FoxPro.

It's kind of ridiculous to think where we've ended up with state of security, where security is one of the top complications in almost any application that gets built today. It's become insanely complex to implement, maintain and keep up to date especially if you follow vendor frameworks like Entra Ids.

Just another moat around the big player's fiefdoms...