In most cases, when you need to debug or test something in the Azure Cloud, you must authenticate yourself against the resource you are attempting to access. Most services require you to utilize OAuth 2.0. If you’re unfamiliar with how OAuth works, here’s a quick explanation.
How does OAuth2.0 work?
In authentication methods like basic authentication, the user credentials (username and password) are sent by the client to the server with each request. The server verifies the credentials, and if they are valid, it allows access to the requested resource.
On the contrary, OAuth behaves differently. No credentials are exchanged between the client and server. Instead, what is exchanged is a token known as a JSON Web Token (JWT). This token consists of a JSON payload that contains essential information required by the server to determine whether access should be granted. The token is encoded in base64 and is included in the HTTP header of every request.
The token can contain information about:
- the requested resource
- validity period
- user/application requesting access
- digital signature
The content of the token can differ from one service to another, and its specifics are not within the scope of this post. The crucial point to remember is that you must obtain a JWT token before making any requests to any resources.
Getting the token
Requesting the token is straightforward. You only need to be aware of a few fields that are required during your token request.
For instance, if I intend to invoke a D365FO custom service for debugging purposes and the link to the service is as follows:
The initial piece of information required to request a token is your tenant ID. You can locate your tenant ID within the Azure portal. Upon logging into the Azure Portal, simply navigate to “Azure Active Directory.”
In the Azure Active Directory, you can locate the tenant ID as illustrated below:
The tenant ID is represented by a GUID. Let’s consider the GUID in our case to be 4a714796-c2f0-440b-b336-c3e1700861a0.
With the tenant ID, we can now build the link through which we will request the token. The basic link follows this format:
https://login.microsoftonline.com/<TENANT ID>/oauth2/v2.0/token
You need to substitute the <TENANT ID> placeholder with your specific tenant ID. In our example, the resulting link would appear as follows:
https://login.microsoftonline.com/4a714796-c2f0-440b-b336-c3e1700861a0/oauth2/v2.0/token
Now, we can begin crafting our request in Postman. Here’s an example of how the request looks for me:
As evident from the image, several parameters must be included in the request:
- client_id: The client ID of the app registration.
- client_secret: The client secret of the app registration.
- scope: The service/resource for which we are requesting a token.
- grant_type: This should be set to client_credentials. (in our scenario).
You can read more about the parameters etc. in the official Microsoft Documentation.
Certainly, it’s important to ensure that the client_id you are using has the necessary permissions to access the requested resource. If you don’t have an app registration, you can create one or request the responsible person to create it on your behalf.
If you observed carefully, you might have noticed the scope. It states:
https://mydevboxxyz.devaos.axcloud.dynamics.com/.default
The .default suffix at the end is of significant importance.
The response from the server should look like this:
How to use the token?
The obtained token can now be directly employed in the actual request to the Dynamics custom service. You can insert the token within the Authorization tab in Postman and choose the “Bearer Token” type.
Conclusion
And there you have it. This is the process for requesting an OAuth 2.0 token and utilizing it to authenticate your request.
Keep hacking