Using OAuth 2.0 in Custom Connectors

This post is part of a series of posts about custom connectors. In this post we’ll look at custom connectors configured with OAuth 2.0 as authentication type. It’s assumed that you are already familiar with how to create a custom connector. If you are not, there are plenty of tutorials in the official documentation as well as from the community. You can also take a look at my old post (yes, it’s a bit old now 😉).

All parts of this series:

1. Revisiting Custom Connectors
2. Using OAuth 2.0 in Custom Connectors
3. Unique Redirect URL for OAuth 2.0 Custom Connectors
4. Exported Custom Connector, where’s my client secret setting?
5. The ALM story for Custom Connectors

Security Settings

Let’s focus on the Security Settings. In my case I chose OAuth 2.0 and Generic Oauth 2 as identity provider. (Why spell it OAuth in one place an Oauth in another? 🤔).

For the client secret and client id I use environment variables. You need to have the client secret in an environment variable in order to get it exported correctly when you export the solution. If you just type in the secret it will not be included in the exported file. The syntax is a bit special, in the field where you want to use an environment variable you type in: @environmentVariables(“myPrefix_MyEnvVar”) You can read about using environment variables in custom connectors here: Use environment variables in custom connectors and here: Connection parameters, OAuth 2.0.

Authorization URL, Token URL and Refresh URL all depends on what the API says of course, for that you will need to study the API documentation for the service/system you want to connect to.

Scope might be used or not. In my case it is used. For the API I’m using, they use scope as a way to define what parts of their services I am authorized to. The parts I want to be able to use (get info from, send into to) are added in there; invoice, customer and project.

Redirect URL will be generated automatically. There has been a recent change in the platform related to the redirect URL and I will write about that in an upcoming post.

About authentication types

When creating a custom connector you can choose between the following authentication types: Generic OAuth 2.0, OAuth 2.0 for specific services, basic authentication and API Key. In an earlier post I had an example in which I used an API Key. There are also examples in the official documentation.

You can read about the different options in the official documentation, e.g. Secure your API (you might not build your own, but use an existing API instead of course). Also under Advanced tutorials there are more information to be found.

Another interesting article is Secure Connectors with APIM in the #30DaysOfLowCode seriese. Also have a look at Day 9a. Build a Custom Connector and Day 9b. Use the Custom Connector.

Also see the landing page for Power Platform and Azure Logic Apps connectors.

Findings

• You need to use environment variables for the client secret in order to get it exported correctly when exporting the solution.
• Scope can e.g. match the scope that the API uses for defining what parts of the API you should be authorized to utilize.
• The synax @environmentVariables(“myPrefix_MyEnvVar”) is used for using an environment variable in the custom connector.
• You can use either a text based or Azure Key Vault Secret environment variable.
• I tried out AKV secrets in environment variables when it was in public preview and used it in a production environment. Note to self: Don’t do that. Don’t use preview features in production. In my case it ended up with me having to recreate the whole environment, I had trouble removing components etc. after some things in the preview function changed. Now it is all GA though. 😊 See Announcing General Availability of Custom Connectors in Solutions as well as Environment Variable Secrets and Use environment variables for Azure Key Vault secrets.

Photo by michael podger on Unsplash