Introduction

This document describes how to create a view in Denodo to fetch the OAuth access token to access OAuth enabled Denodo web services. We will focus on Microsoft Entra ID (Azure Active Directory) as  Identity Provider.

Microsoft Entra ID is Microsoft's cloud-based identity and access management service. It was formerly known as Azure Active Directory. It is designed to help organizations to manage users and provide secured access to resources, such as applications and data, both on-premises and in the cloud.

The steps in this document include creating a JSON data source to construct the API call for token retrieval. Later, by executing the base view created on top of the JSON data source, the API request for access token retrieval will be processed by Microsoft Entra ID and the token will be retrieved.

Prerequisites

This document assumes the configuration for publishing a web service with OAuth authentication is already done in Denodo. You can refer to How to configure published web services with Oauth and Azure AD for more information on this.

To generate OAuth tokens to access Denodo Web Services:

• Ensure that the user initiating the OAuth token request has the necessary permissions configured for the Microsoft Entra ID account.
• Ensure that the details of the registered Azure application, including the Application (client) ID, Client Secret, Directory (tenant) ID, and any other required information for constructing the authorization request and token exchange are available prior to the setup.

This information is crucial for proper authentication and authorization processes.

The following OAuth Grant flows will be discussed in this article:

• Resource Owner Password Credentials grant.
• Client Credentials grant .

Each of the OAuth Flows are detailed below. Please note that each configuration will vary depending on the different grants.

Resource Owner Password Credentials Grant

Microsoft Entra ID

• In the application created in Microsoft Entra ID, navigate to the ‘Authentication’ tab.
• In the Advanced settings, set ‘Allow public client flows’ to Yes. Save the configuration.

Note:  When you enable “Allow public client flows” you are allowing public clients to request tokens without presenting a client secret. It's crucial to assess the security requirements of your application and the specific use case before enabling this option. Hence, always follow security best practices as per the organization standards and stay informed about changes in Azure AD policies and configurations.

JSON data source

• From the Virtual Dataport Administration Tool / Web Design Studio, create a new JSON data source by selecting “File > New > Data source > JSON”. This will open the wizard to configure the  connection.

• Choose the Data route as “HTTP Client”

• In the ‘Configuration’ tab, select Default HTTP method as POST.
• BaseURL: https://login.microsoftonline.com/<tenant_id>/oauth2/v2.0/token

Replace the <tenant_id> with the tenant ID obtained from the Azure Portal.

• Select ‘Post body’ and provide the below details which will be sent with the Base URI.

You may also consider parameterizing the username and password like   “&username=@azure_account” and “&password=@azure_password” to dynamically pass the user credentials from whoever accesses it. If you want to retrieve the refresh token as well, add offline_access as part of the scope parameter.

• Click on  ‘HTTP headers’ and set Content-type as “application/x-www-form-urlencoded”

• Check ‘Test connection’. Once the connection is successful, create a base view using the ‘Create base view’ option.

By running this view you can get the access token and refresh token to access the OAuth enabled Denodo web services from an external API application.

Note: The Resource owner and password credentials flow is not applicable when Multi Factor Authentication is enabled for the Azure account.

Client Credentials Grant

Microsoft Entra ID

Create an app role

• Go to the App roles section of the Application and click on +Create app role.

• Configure the necessary values and click Apply:

• Display name: Name to be displayed for the app role.
• Allowed member types: Specifies whether this app role can be assigned to users, applications, or both.

• Value: defines the role's claim value that the application should anticipate from the token. This value is the name that should be created as a role in Denodo to grant the necessary privileges. For example, denodo_read as mentioned below.

Give API permissions to the app roles

• Go to the application, select  'API permissions' > '+Add a permission'.
• The 'Request API permissions' window will open and  navigate to 'My APIs' and select the application.

• Choose the 'Application permissions' and select the role(s) you want to give the permissions to.
• Select the ‘Add permissions’ button to complete the addition of the role.

Role creation

Create a  role with the same name (denodo_read) in Denodo and provide the proper privileges to the role.

Note: The role should be created in Denodo with the same name as the Value of the role created in Microsoft Entra Id. Check it in the ‘App roles’ section of the application.

JSON data source

To configure the JSON data source follow similar steps to the ones provided in the section  Resource Owner Password Credentials. with the following changes:

• For the ‘Post body’ provide the below details.

For the scope parameter add /.default at the end

For instance: &scope=api://*********************/.default

• Configure the ‘HTTP headers’ as before (set Content-type as “application/x-www-form-urlencoded”) .

• Verify the configuration is valid with the ‘Test connection’ option and create a base view to get the tokens.

• After these steps, you will be getting theOAuth tokens just by executing the view.

These access tokens can then be used to access Denodo web services with OAuth from any external API applications.

Client Access

Below is an example from the Postman application. Under the authorization section you can select Bearer Token as type and include the token obtained from executing the view we have just created.

Authorization: Bearer <access_token>

References

JSON Sources

Authorization Code Flow

Client Credentials Flow

Resource Owner Password Credentials