Power Platform Community Forum Thread Details

Custom connectors configured with "Generic OAuth 2.0" security define an Authorization URL, Token URL, and Refresh URL in the connector's securityDefinitions. The authorization code exchange and token refresh against these URLs are performed server-side by the Power Platform connector backend, not by the connector's own request pipeline (the operations and policies defined via Swagger).

Any header customization available to connectors (request transformation policies, header parameters on operations, etc.) only applies to calls against the connector's defined API operations. It does not apply to the OAuth handshake itself (authorization code exchange and token refresh) because that traffic never passes through the maker-defined policy layer...

This is becoming a practical blocker. In our instance, we are looking to connect to Canvas LMS (Instructure). They have begun enforcing a User-Agent header requirement on all API requests in production as of this month and rejecting requests that lack one. Other API providers are adopting similar practices as a basic observability measure. Connectors built against these APIs using Generic OAuth 2.0 now fail at the "Authorize" step. The user completes the consent screen, but the subsequent server-to-server token exchange is rejected by the API because it lacks a compliant User-Agent header. Surfaced errors only indicate the lack of User-Agent header.

I'm looking for a supported way to specify static headers (at minimum, User-Agent) that the connector backend includes when it calls the Authorization URL, Token URL, and Refresh URL (either as an additional field in the securityDefinitions OAuth2 block--e.g., an x-ms-* extension--or as a connector-level setting in the Security tab UI). Alternatively, ensure the platform's own OAuth handshake requests always include a sensible default User-Agent (e.g., identifying the requesting environment/tenant) so they aren't blanket-rejected by APIs enforcing this requirement.

Thanks in advance for any insights you might provide.

Categories:

Using connectors

Connector development

This is a very valid scenario, and your understanding is correct.

For custom connectors using Generic OAuth 2.0, the token exchange and refresh calls are handled by the Power Platform connector backend. They do not go through the custom connector operation pipeline, so policies, header parameters, and request transformations do not apply to the OAuth handshake itself.

Because of that, there is currently no supported maker-side setting that I am aware of to add a custom static header, such as User-Agent, specifically to the Authorization URL, Token URL, or Refresh URL calls.

Possible workarounds are limited:

Ask the API provider to allow Microsoft Power Platform OAuth/token requests or relax the User-Agent enforcement specifically for token endpoints.

Use a middleware/proxy endpoint for the OAuth/token exchange that adds the required header before forwarding the request to Canvas LMS.

If available, use a different supported auth pattern that avoids this specific token exchange limitation.

Raise this as a Microsoft support case or product feedback item, because this would likely require a platform-level enhancement.

I agree this is a practical blocker. A connector-level option to define headers for OAuth token and refresh requests, or a default Power Platform User-Agent on backend OAuth calls, would be a useful improvement.