Unique Redirect URL for OAuth 2.0 Custom Connectors

This post is part of a series of posts about custom connectors. In this post I’ll remind you about the fact that you might have some old custom connectors that you need to take care of in case you created them using the common redirect URL, which earlier was the default option! February 17, 2024 was an important date, but if you did not pay attention to this then, it is not too late to do it 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

There was an important change introduced in the platform earlier this year. Before we could create a custom connector and use a common global redirect URL. Nowadays when you create a custom connector, a unique redirect URL is created automatically.

What happens if I don’t?

If you do not update your existing custom connectors using OAuth 2.0 to use a unique redirect URL you will not be able to create new connections. The existing connections will continue working, however if, for some reason, the connection breaks in one of your environments, you will not be able to successfully authenticate anymore, i.e. won’t be able to fix the connection and your cloud flows (or other components) using your custom connector will not be able to do so successfully anymore.

Update connector to use unique URL

In my case, I got a warning that I needed to update the custom connector.

In order to fix it, navigate to the custom connector, open it, edit the security settings. In my case there was a checkbox available for upgrading to use a unique redirect URL, I had this in my development environment only, where I have the custom connector in an unmanaged solution. When I had updated it I got a confirmation.

There is a chapter in Microsoft Learn which describes this as well as how to update if your custom connector was created with multi-auth using the CLI tool. You can also read:

Newly created custom connectors that use OAuth 2.0 to authenticate automatically have a per connector redirect URI. Existing OAuth 2.0 connectors must be updated to use a per-connector redirect URI before February 17, 2024.

We’ll enforce this update for existing OAuth 2.0 custom connectors starting on February 17, 2024. Any custom connector that hasn’t been updated to use a per connector redirect URI stops working for new connections, and shows an error message to the user.

Add ALM to that

When I had updated my custom connector in the development environment and made sure to use the new redirect URL where I manage client id/secrets for this API, then all was good in the development environment. (I probably re-created the connection by the way).

Then in theory, I would then deploy the custom connector to my test environment, make sure to change in the portal for the service/API I’m using to set the new redirect URL and make sure environment variables in test are OK (client id and client secret).

However, after deploying the custom connector to my test environment, I encountered a new issue. Even though I double-checked the client id, client secret (environment variables values in test) and had added the redirect url to the service portal (where I manage client id/secrets for this API), I could not create connections successfully! All ok in dev, in test, not so ok. To be continued! In the next post, I’ll let you know how this story ended.

Findings

• Nowadays you need to use a unique Redirect URL for custom connectors.
• If you have an old custom connector using OAuth 2.0 you need to update it in case you used the global common redirect URL when you set it up. It was the default option earlier!
• After you have changed to use a unique URL, make sure to update to use this URL (where to update depends on the service/system you are connecting to).
• It is not super easy to find information about fixes. In the Power Platform Admin Center we can see a few messages from the M365 Admin Center if we have chosen to see that “card” on the start page. When we navigate to M365 Admin center it is not super easy to find what you are looking for. You might not be authorized to see it. I’m not sure how far back we can look either. I do not see the message that is mentioned in this particular case, MC690931. Found in a comment here. Might just be me not knowing how to best search for it.

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

Photo by Douglas Bagg on Unsplash