有客，用第三方物流之API，此API非Power Automate内置连接器目录所载。其API言OAuth2授权码之流程。平台有“创建自定义连接器”之流程，声称数点击即可处理OAuth2。吾辈以此法所建前二连接器皆功。及至第三，遇三别之问题，合之需一周以辨之。

此三者之状，及今时所验于OAuth2定制连接之式.

定制连接OAuth2之流所当为者

尔填表，具：

• 客户ID
• 客户密钥
• 授权URL
• 令牌URL
• 刷新URL（通常同于令牌URL）
• 范围
• 重定向网址（由Power Platform自动生成）

平台自为之：导引用户以授权，捕获授权码，易之以为访问令牌，过期则更新。当流程使用此连接器时，当前访问令牌自动注入于授权头。

此法可行，惟身份提供者恪守OAuth2之规范。若提供者取寻常非规范之捷径，则平台不显其弊，此法遂破。

警惕一：重定向URL系租户专属，汝硬编码于IdP中。

汝于物流API之OAuth应用，以自开发环境所复制之重定向URL而配置之。开发之定制连接器，运作无碍。汝将此方案导出至用户验收测试环境，复导入之，然首度OAuth授权同意于用户验收测试环境失败，报"重定向URI不匹配"之错。

根本之由：Power Platform所生之重定向URL，含环境特有之租户子域名。开发环境之URL，非用户验收测试环境之URL也。

修：于身份提供者处注册众重定向URL，每平台环境一URL。OAuth应用于身份提供者侧，需为每一https://global.consent.azure-apim.net/redirect/* URL，与诸环境相应者，各设一录。

曲折：有身份提供者，于重定向URL注册，容通配符（https://global.consent.azure-apim.net/redirect/*）。者有之，

者无之。严苛者，则列名册，时而增删，以应环境之变。

陷二：刷新令牌之理 __JHSNS_SEG_06573942_23__所接之API，发授令牌，一时有效者一箇时辰，更新令牌者三十日。权能平台当令牌将尽，自能更新；尔毋需三十日内复请授权。

所发生者：每二时，流始败，得四十百一，曰"未授权"。手自授权，则愈；二时后，复如是。

诊断颇费时日。流之运行史载，令牌被用，API拒之，然无刷新之试。终溯其源，乃接续于OpenAPI之谱所陈之刷新行止：接续者未设refreshUrl，故平台视每令牌为终局，不复试刷新。

修：于连接器之安全篇，明设refreshUrl，纵与tokenUrl同。无此，平台即以为不支刷新。

吾等所察次一问题：有API每刷新必更替令牌（与新授权令牌并返新刷新令牌）。若响应之JSON含refresh_token，则Power Platform能正确处理。然API仅于初次授权时含refresh_token，于刷新时则无，终将使所存刷新令牌过期，而需再授权。此乃提供者之行为，于连接器不可修正——汝唯可于刷新令牌之生命期将尽前，调度手动再授权。

陷坑三：此API需一自定义参数名，而OAuth2之规范未及之

标准OAuth2之令牌交换，则发grant_type=authorization_code，code=, redirect_uri=, etc. in the form body.

The API we were connecting to wanted an additional tenant_id parameter on every token exchange. It is not part of the spec; the provider added it for their multi-tenant SaaS model. Power Platform's custom connector OAuth2 configuration does not have a field for "extra parameters to send on token exchange." Default behavior sends only the spec-defined fields. The fix we used was hacky: move the OAuth flow behind an Azure Function. The flow calls the function's HTTPS endpoint, the function does the token exchange with the full set of parameters and returns the access token, the flow uses the access token via a separate connector that expects Bearer auth. This doubled the integration complexity (an extra hop, an extra resource to monitor) but was the only working path. We later migrated to direct connector when the API provider added spec-compliant OAuth as an option. The broader lesson: before building a custom connector with OAuth2, confirm the target API follows OAuth2 strictly enough to work in the platform's constrained configuration. Providers that require custom token exchange parameters, non-standard response fields, or DPoP/mTLS cannot use the built-in OAuth2 flow - and the connector wizard does not warn you. ## The pre-check we run before building an OAuth2 connector Ten minutes of reading provider docs before clicking "New custom connector" saves hours later. Our checklist: 1. Does the provider document the authorize URL, token URL, and refresh URL? (All three needed; "refresh works same as token" is the common case but confirm.) 2. Does the provider accept wildcard or multiple redirect URLs, or only one? (If only one, you need an extra OAuth app per environment.) 3. Does the provider rotate refresh tokens on refresh, and what are the lifetimes? (Shorter refresh lifetime means more re-auth pain.) 4. Does the token exchange require any parameters beyond the OAuth2 standard set? (If yes, you likely need an Azure Function proxy.) 5. Does the API require PKCE? (Power Platform supports it for some flows; confirm.) Any "no, not sure" on these is a reason to de-risk before committing the full integration. ## The connection reference hygiene A custom connector deployed to managed solution uses connection references for per-environment auth. One connector, one connection reference, N connections (one per environment, each bound to its own OAuth authorization). For the auth to actually carry across environments: - Create a long-lived connection per env at initial setup (authorize once, test works) - Ship the connection ID in the deployment-settings.json for each env - Rotate/reauthorize only when the refresh token lifetime runs out A connection reference that is re-bound mid-release will break every running flow. We now treat OAuth-backed connection references as nearly immutable - rebinding is an ops event, planned, communicated. ## The fourth pitfall we almost had On a subsequent project, we almost repeated a mistake: committing an OAuth client secret into the deployment-settings file. The file is in git. The secret would have been in git history forever. Pattern we now enforce: OAuth client secrets live in Azure Key Vault. A secret-type environment variable references the Key Vault secret URI. The deployment-settings file references only the env variable schema name, not the secret value. Git gets the schema name; Key Vault gets the secret; nothing sensitive lives in both. Four pitfalls, one prevention pattern each. Built into the project template, the custom-connector work that used to eat weeks now takes days.