In today’s automated world, businesses depend on secure, streamlined connections between systems to improve efficiency. Power Automate, a robust tool for building workflows between various services, allows seamless integration of applications and APIs. However, when working with third-party services, ensuring that data access is secure and well-managed is critical. This is where OAuth 2.0, a secure and standard protocol for authorization, comes into play. Are you struggling to configure OAuth 2.0 authentication in your Power Automate flows? If you are considering automating workflows that interact with secured APIs, this article is for you. I will walk you through configuring OAuth 2.0 in Power Automate, so you can ensure the safety of your automation while keeping your services accessible. Why OAuth 2.0? OAuth 2.0 is the industry-standard protocol for authorization. It allows users to grant third-party applications limited access to their resources without exposing passwords. By using OAuth 2.0 in Power Automate, you ensure that the services and APIs you connect to are secure, and that tokens are used to access data on behalf of the user. How OAuth 2.0 Enhances Security OAuth 2.0 significantly improves security by eliminating the need to share sensitive credentials. Instead, access is granted through tokens, which are time-limited and easily revocable. OAuth 2.0 is widely used by many companies, including Microsoft, Google, and Salesforce, to integrate applications securely. Step-by-Step Guide to Configuring OAuth 2.0 in Power Automate 1. Set Up OAuth 2.0 Credentials Before configuring OAuth 2.0 in Power Automate, you need to set up OAuth 2.0 credentials in the platform you’re working with. For example, if you’re using Microsoft Graph API or any third-party service, follow these steps: 2. Initialize OAuth 2.0 Variables in Power Automate Now that you have your client ID and client secret, it’s time to configure them in Power Automate. Set up the variables: 3. Configuring the OAuth 2.0 Connection in Power Automate With the client credentials set, it’s time to establish the connection to the service using OAuth 2.0. 4. Use OAuth Token to Access Secure Data Now that you have the OAuth token, you can use it to authenticate your requests to third-party APIs. 5. Best Practices for OAuth 2.0 in Power Automate To conclude, OAuth 2.0 authentication provides a secure and effective way to authorize third-party applications in Power Automate. By following the steps outlined in this guide, you can set up OAuth 2.0 authentication, ensure data security, and integrate third-party services into your automation workflows with ease. If you’re ready to secure your Power Automate workflows with OAuth 2.0, follow the steps outlined in this post and start integrating APIs in a secure manner today. For more tips and detailed guides, check out our other blog posts on Power Automate and API integration. Need help with the OAuth 2.0 integration? Feel free to reach out for assistance! We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

Introduction Postman is an essential tool for developers and IT professionals, offering a robust platform for testing APIs, automating test processes, and collaborating efficiently across teams. In this blog we’re going to connect Postman to our Finance and Operations environment so we can test out standard or custom APIs. This connection is a crucial step in ensuring that your APIs function as expected, and it helps streamline the integration of various business processes within your organization. Whether you’re new to API testing or looking to optimize your current setup, this guide will walk you through the process with clear, actionable steps. I’ve already covered automating the testing in Postman in my blog here so once the connections are in place you’ll be good to go! Pre-requisites Configuration We’ll start with creating an App Registration in Azure Portal. Go to the Azure Portal (of the same tenant of your FnO Environment). Search for “App Registration” and click on “New Registration”. Add a name for your new app and click on “Register.” Once it is completed, you’ll be taken to the Overview of the app. Here, click on the “Add a certificate or secret” under the “Client Credentials.” Add an appropriate name and select the expiration date of the certificate as necessary. Once you click on add you’ll get the confirmation message that the client credential has been created and you’ll be able to see the value of the secret. ** Be sure to copy this value and keep it securely as once we refresh from this page, this value will not be available. ** Now that everything is done on the Azure side, open your FnO environment and search for “Microsoft Entra Applications.” Click on “New.” Paste the “Application (Client) ID” into the “Client ID” field, then assign it a suitable name and a User ID.  The permissions given to the User ID will determine the permissions for the App. For now, I’ve assigned the “Admin” user. That’s all the configuration required at the FnO side. Now, let’s jump back into Postman. Now, in Postman we’ll start with a blank workspace and create a simple collection. The first thing that I like to do is to create different environments. As in FnO, we have a Production, a Sandbox and we can have multiple development environments so it may be possible that different environments are using different apps. So, to represent these environments, I like to create different environments in Postman as well. This is done by going to the “Environments” then clicking on “+” to create a new environment and giving it the appropriate name. Now, in this environment, I’ll add my app details as environment variables. The values for these can be found as follows –  “grant_type” can be hard coded to “client credentials” and we can leave “Curr_Token” as blank for now. So, at the end we get – We can also change the type to “Secret” so that no one else can see these values. Now, the necessary credentials have been added to Postman. Next, we’ll set up our collection for generating the Auth Token. For that, we’ll copy the “OAuth 2.0 token endpoint (v2)” from the “Endpoints” in our Azure App Registration’s Overview screen. In Postman, click on your Collection then “Authorization” then selects “OAuth 2.0” I’ll paste the URL we copied from the “OAuth 2.0 token endpoint (v2)” from the “Endpoints” in our Azure App Registration in the “Access Token URL” field and I’ll add my variables as defined at the Environment variables. If you get the error “Unresolved Variable” even after defining them, then it could mean that the Environment isn’t set as the active. So go back to the Environments list and mark it as active. This way we can easily swap between Environments. Once the environment is marked as Active, we can see that the variable is found correctly. I’ll also ensure that my Access Token URL refers to the tenant ID as per my variable by embedding my “tenant_id” variable in it. Next, I’ll click on “Get New Access Token.” If everything has gone well, you’ll be able to generate the token successfully. After that, you can give it a name and click on “Use Token” to use it. I’ll now create a simple API which we can use to test this token. Right click on the “Collection” and click on “Add Request” give it an appropriate name. The “{{base_url}}/data” returns a list of APIs available in the system. I’ve set the Authentication to “Inherit Auth from parent” which means it relies on the Authentication set on the “Collection” for calling the request as is shown on the right side of the screen. Here we see that the request was executed successfully. If for some reason, you cannot use the standard Postman way of generating the Token, you can create a seperate API responsible for generating the Auth Token, store it as a variable and use it in your requests. From here, you can use the generated “access_token” and pass it as a “Bearer Token” to your requests. Or you can select the entire token and set it to your “Curr_Token” variable. And then you can pass this variable to the requests like –  From Postman, we can then share these collections (which contain API data) and environments (which contain credentials) seperately as needed. All Data Entities follow the pattern – {{base_url}}/data/{{endpoint}} All services follow the pattern – {{base_url}}/api/services/{{service_group_name}}/{{service_name}}/{{method_name}} If I call a “Get” request on them, I get the details of the services for instance, here I’m getting the type of data I have to send in and the response I’ll be getting back in the form of object names. Moving back one step, I’m getting the names of the Operations (or methods) within this service object. Moving back one step, I’m getting the services within this Service Group. Moving back one step, I can see all the service groups available in the system. To actually run the logic behind the services … Continue reading Leverage Postman for Streamlined API Testing in Finance and Operations →