6.2 Authentication and Policy Templates for Custom Connectors
Key Takeaways
- Custom connectors support five authentication types: No authentication, Basic authentication, API Key, OAuth 2.0, and Windows authentication.
- OAuth 2.0 against Microsoft Entra ID requires a Client ID, Client Secret, Authorization URL, Token URL, Refresh URL, and scope from an app registration.
- Windows authentication only works for on-premises APIs reached through an on-premises data gateway.
- Policy templates modify a connector's runtime request or response behavior — headers, query parameters, base URL routing, timestamp formats, paging, and transformations — without changing the underlying API.
- Policies apply consistently to every connection and every flow or app that uses the connector, so makers never duplicate the logic themselves.
Every custom connector must declare how it authenticates to the underlying API on the Security tab. PL-400 expects you to know the five supported authentication types and when each applies, because choosing the wrong one is a common design mistake that surfaces as either a security gap or a connector that simply cannot connect.
The Five Authentication Types
| Type | How it works | Typical use case |
|---|---|---|
| No authentication | No credentials are sent at all | Public, unauthenticated APIs (e.g., open weather or reference data feeds) |
| Basic authentication | Username and password are Base64-encoded into the request's Authorization header on every call | Legacy or internal APIs that check a simple username/password pair |
| API Key | A key value is sent as a request header or query-string parameter; the maker names the parameter and its location when configuring the connector | APIs that issue a static subscription or developer key |
| OAuth 2.0 | The connector exchanges credentials for a bearer token using an identity provider — either a generic OAuth 2.0 provider or a built-in provider such as Microsoft Entra ID (Azure AD) — configured with a Client ID, Client Secret, Authorization URL, Token URL, Refresh URL, and scope | Modern APIs, and any Azure-hosted service secured with Entra ID |
| Windows authentication | Uses Windows (NTLM/Kerberos-style) credentials, and only works for APIs reachable through an on-premises data gateway | On-premises REST APIs behind a corporate firewall |
For OAuth 2.0 against Microsoft Entra ID (Azure AD) specifically, the connector needs an app registration in the tenant: the Client ID and Client Secret from that registration, the tenant-specific authorization and token endpoints, and the scope (resource) the token should be issued for. This is the pattern used when the custom connector fronts an Azure Function App, Logic App, or any Azure resource secured with Entra ID — the connector authenticates as the signed-in user (or a service principal, in flow-to-flow scenarios) and Entra ID issues the access token the API validates.
A design detail worth remembering for the exam: the authentication type is fixed for the connector as a whole — every action shares the same scheme — so an API that mixes, say, an unauthenticated health-check endpoint with authenticated business endpoints either needs two connectors, or the health-check endpoint has to accept the same credentials as everything else.
Policy Templates: Modifying Runtime Behavior
Policy templates let you change how a connector behaves at request or response time — without touching the API itself or forcing a maker to redo their flow. They are added from the Definition tab (+ New policy), and multiple policies can be stacked and reordered; each runs against either the outbound request or the inbound response.
Common built-in policy templates include:
- Set query parameter value — inject or override a query-string parameter on every outbound request (e.g., forcing an
api-versionvalue). - Set http header — add, replace, or remove a request or response header (e.g., attaching a static subscription key header the API expects).
- Route requests to a different base URL — redirect calls to a different environment's base URL (useful for routing test vs. production traffic, or region-specific endpoints) without editing the connector definition itself.
- Convert timestamp format — reshape a date/time value between the format the API returns and the format Power Platform expects.
- Data retrieval using dynamic values / paging support — help the connector page through large result sets automatically.
- Advanced request/response transformation — a template that accepts custom transformation code for reshaping a payload that does not match Power Platform's expectations.
- IP address filtering — restrict which caller IP ranges are permitted to invoke the connector.
Each policy template exposes its own configuration parameters (for example, the header name and value, or the target base URL), and because policies operate at the connector layer, they apply consistently to every connection and every flow or app that uses the connector — a maker never has to duplicate the logic themselves. This is the mechanism PL-400 expects you to reach for when an API's raw behavior does not quite fit Power Platform's conventions and rewriting the API itself is not an option.
Validating Security and Policies on the Test Tab
Authentication and policy configuration are only confirmed to work once they are exercised against the real API, which is exactly what the Test tab is for. After saving the connector (Create connector or Update connector), a developer creates a new connection — walking through whatever the Security tab's authentication type requires, from an OAuth 2.0 consent prompt to an API Key entry field — then selects an operation, supplies sample parameter values, and runs Test operation. The tab surfaces the raw outbound request (including any headers or query parameters a policy template injected) and the raw inbound response, so a developer can immediately see whether a policy fired as expected, whether the OAuth token was accepted, or whether an API Key was sent in the wrong location. Because policies apply silently in the background, this request/response view is often the only way to confirm a policy is actually doing what it was configured to do before handing the connector off to makers.
A custom connector needs to call an Azure Function App that is secured with Microsoft Entra ID. Which authentication type should the connector use?
Which policy template would a maker use to redirect a custom connector's outbound calls to a different environment's base URL without editing the connector's definition?