I’m primarily a network guy who happens to know how to code. It’s useful to be able to demonstrates to a software guy that no, it’s not the network and this is how your application should do things
I will take an educated guess, your window frame supplier enagaged a contractor. The contractor used an Azure backend and the credentials you have been handed are actually for the app the contractor produced.
Azure is a container for many different apps, services and resources. Before you can accesss the apps, services and resources inside the container, you first have to gain entry to the container. As this container is operated by Microsoft who are an attractive target for Nation state sponsored hackers, don’t expect it to be as simple as a username and password. The magic roon you are missing is the ‘authentication flow’ - How your app negotiates sign-in and connection to the particular resources it is permitted to access?
There is no one universal method I am afraid. There are many methods, each one intended for a specific scenario or use case. M2M (machine to machine) apps authenticate differently to B2C (business to consumer) and so on. Each different app has an authentication flow created and configured in Entra ID (formerly Azure Active Directory). The concept is similar to creating a user account. Even simple user accounts in Entra have their own authentication flow - A password, an authenticator app or other MFA, or conditional access, or a combination.
Entra is a subject in it’s own right with a steep learning curve that I am still negotiating. A little light reading to get you started…
Microsoft identity plaform
Call an ASP.NET Core web API with cURL
To attempt a summary…
As far as I know all access to the Microsoft Cloud now needs to negotiate an OAuth2 (Modern authentication) layer. For B2C apps with an end UI and browser access this is typically achieved by ‘delegation’ - Your app redirects to the Entra sign in which redirects back with a security token. For M2M an app may exchange a Client ID and Client secret, generated when the app was registered in Entra, for an access token that grants a ‘scope’ of priveledge. The access token is then attached to HTTP request headers. Access tokens usually expire at some point and need to be refreshed to maintain integrity of the session.
Modern Authentication gets you inside the Microsoft Cloud, the container. Then you need to connect to the resources, apps, services, apis, storage etc. Primary and secondary keys are used to access Azure blob storage from a REST API. Permission to use the blob is configured in Entra. Subscription Keys may be used to secure access to API calls, and are again configured in Entra.
Too many unknowns to get a catagorical answer here. Almost certainly either you or your supplier needs to take a look at the Entra portal…And have a clue what it all means.
Any chance your supplier can put you in touch with their developer, or a customer who is using the API? It’s a lot of guessing to reverse engineer.