oAuth 2 protocol, Microsoft Azure cloud services 1

[Steve Yu]

Fellow colleagues.

Does VFP have commands that is capable of reaching endpoints that's only accessible via oAuth 2 protocol based on Azure ?
There are sample codes in various languages except VFP in GitHub.
Just wonder if it's feasible with VFP code alone (one of our guys wrote a routine in C# and built a DLL, that can be called from within VFP, that can do the trick).
Is there a more elegant way ?

Help appreciated.

Steve Yu

 

[Scott24x7]

Hi Steve,
No, but you can use WinHTTP com object.
I use this to interface with OpenAI GPT-4o.
ChatGPT suggests this approach:

LOCAL oHTTP
oHTTP = CREATEOBJECT("WinHttp.WinHttpRequest.5.1")

* Obtain the OAuth token
oHTTP.Open("POST", "https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token", .F.)
oHTTP.SetRequestHeader("Content-Type", "application/x-www-form-urlencoded")
oHTTP.Send("client_id=...&client_secret=...&grant_type=client_credentials")
lcTokenResponse = oHTTP.ResponseText

* Parse the access token from the response
lcToken = EXTRACTTOKEN(lcTokenResponse)  && You need to parse the JSON.

* Use the token in an API call
oHTTP.Open("GET", "https://api.example.com/data", .F.)
oHTTP.SetRequestHeader("Authorization", "Bearer " + lcToken)
oHTTP.Send()
lcApiResponse = oHTTP.ResponseText

You'll have to sort out the JSON return as well, and you'll need an API Key.

 

[Steve Yu]

Thanks for the tip, Scott.
One of the requirements of this project was base64 encoding; where does this fit into the process you described ?

Regards,

Steve Yu

 

[MathiasB]

I find convinient to just code my own com component in c#. Then use that in vfp.

 

[Steve Yu]

I find convinient to just code my own com component in c#. Then use that in vfp.

Yes, that's what we did so far.
But we have also been able to code in 'native' VFP most other integration projects in the past.
It is much easier to maintain.
Here I'm stumped on the use of private key, with base64 encoding, of certificate for oAuth 2 validation on Azure.

 

[Michele65]

For these operations i use Chilkat's controls... They make the connection very easy.

 

[Steve Yu]

For these operations i use Chilkat's controls... They make the connection very easy.

Can you provide an example ?

 

[Chris Miller]

To the last question: https://www.example-code.com/foxpro/default.asp
Also, Bill Anderson maintains a library to make easier use of Chilkat libraries in VFP. I personally think Chilkat provides everything you need, but it may be helpful anyway, to know Bill Andersons GitHub repository for ChilkatVFP: https://github.com/billand88/ChilkatVFP

But then, Scotts example is already making things clear. First things first:

1. For OAuth2 you need to get a token from the site to use in all your following requests
2. Then you provide that token in an authorization header, Scotts essential line covering oAuth2 for all requests after initially getting a token is that:

oHTTP.SetRequestHeader("Authorization", "Bearer " + lcToken)

No matter if you use WinHttp.WinHttpRequest.5.1, Msxml2.ServerXMLHTTP.6.0,, Chilkats or any other http rerquest class, the method names may vary slightly, but you set a http request header.

For base64, VFP has STRCONV(). that's a completely separate conversion issue.

Well, and once more first things first: The inital things you need to get the token are Azure "credentials" you can find or set up in your Azure account. A client ID, API key, clent secret, whatever. You have to fill the gaps in Scotts sample code, of course. If your .NET assembly has this all encapsulated and you have no hands on your (companies) Azure account, you can't recode that in VFP and better make use of that assembly. Nobody here and no library from a third party will know your Azure credntial API keys and secrects, of course.

And then, there's still enough more to implement with JSON or XML parsing, deserialization, processing in general, for which you'll find libraries on GitHub or from West Wind or Chilkat, too.

 

[Steve Yu]

To the last question: https://www.example-code.com/foxpro/default.asp
Also, Bill Anderson maintains a library to make easier use of Chilkat libraries in VFP. I personally think Chilkat provides everything you need, but it may be helpful anyway, to know Bill Andersons GitHub repository for ChilkatVFP: https://github.com/billand88/ChilkatVFP

But then, Scotts example is already making things clear. First things first:

1. For OAuth2 you need to get a token from the site to use in all your following requests
2. Then you provide that token in an authorization header, Scotts essential line covering oAuth2 for all requests after initially getting a token is that:

oHTTP.SetRequestHeader("Authorization", "Bearer " + lcToken)

No matter if you use WinHttp.WinHttpRequest.5.1, Msxml2.ServerXMLHTTP.6.0,, Chilkats or any other http rerquest class, the method names may vary slightly, but you set a http request header.

For base64, VFP has STRCONV(). that's a completely separate conversion issue.

Well, and once more first things first: The inital things you need to get the token are Azure "credentials" you can find or set up in your Azure account. A client ID, API key, clent secret, whatever. You have to fill the gaps in Scotts sample code, of course. If your .NET assembly has this all encapsulated and you have no hands on your (companies) Azure account, you can't recode that in VFP and better make use of that assembly. Nobody here and no library from a third party will know your Azure credntial API keys and secrects, of course.

And then, there's still enough more to implement with JSON or XML parsing, deserialization, processing in general, for which you'll find libraries on GitHub or from West Wind or Chilkat, too.

Great insight, Chris.
Have been using West Wind's class library for all our API integration projects (XML,JSON decoding included); but this one seems more complicated.

".. you have no hands on your (companies) Azure account .."

That may be the situation we have here. Instead of client secret (since we don't have control over the account, it'd be hard for our trading partner to provide the secret each time it is renewed), we are provided with a certificate from which we are suppose to generate a private key to include in the authentication process, along with provided tenant ID, client ID, scope, etc. The documentation says we can go the long way or use MSAL to simplify the process. I understand the flow of "get the authentication token , pass the token to API, decode ". But the devil is in the detail. In particular the part of "base64 encoding of certificate key' to pass the authentication step.

Steve Yu

 

[Chris Miller]

the devil is in the detail. In particular the part of "base64 encoding of certificate key' to pass the authentication step

Well, once more STRCONV will convert to base64. Look it up, it's

STRCONV(cExpression, nConversionSetting)

With nConversionSetting 13 according to the help.

So the base64 encoding of whatever key value is

cKeyBase64=STRCONV(cKey, 13)

I see you're not using Azure yourself, just providing the feature, so either you provide a configuration setting or use a mechanism as you describe to get at the actual client id/secret or other values you need to run azure requests from there, but base64 is not a cryptographic encryption method or such, it's just converting any binary value into an about 33% longer value consisting of 64 diffferent ASCII characters, each 6 bits are converted to an ASCII character. You might even already get the key in base64 format, which you could deduce from the key value only containing letters, digits or + and / and = as padding character. In that case you even do nothing with that.

If your key string is only digits and letters a-f, then what you have is a hex representation of the binary key, to get that to base64 you first need that in binary, each two hex digits convert to one byte value 0-255 (00 to ff). And then apply STRCONV to that,

Since usually a key is a binary random bit combination but you retrieve it through http or on a web page, it's not provided as the key itself but as hex or base64 representation. This should be clear by documentaion/description. Nobody can do the nitty grirtty work of getting into the details for you, as they key is secret, even more so as it's the key of your customer/trading partner. Secrets are of course bound to be kept secret, so even if you can write code that getes their key from somewhere (I read about an Azure key vault, that could be where it resides) to test that code your code would get at the secret you personally shouldn't get at. In the end, there will need to be some level oof trust to get anywhere near the key that enables doing any Azure request.

So to be able to code for Azure, your company should have their own Azure account and you then develop and test code with that and later put in the key retrival process for code working with the secret of your partner. The core problem with all such things is that you need a secret to get at another secret, you can always only shift the problem to another secret which then logically has the same value and has to be kept.