Setyenv · Docs
  • English
  • Spanish
  • Chinese
  • Japanese
  • Arabic
  • German
  • French
  • Hindi
  • Indonesian
  • Italian
  • Dutch
  • Portuguese
  • Russian
  • Turkish

OAuth outbound connections

When a workflow has to authenticate to a third-party API with OAuth 2, the connection — client id, client secret, endpoints, scopes and the live tokens — is defined and stored in WP-PFManagement. Workflow runs the certified OAuth flows and applies the resulting bearer token to your outbound calls automatically. You create and authorize the connection in Management — see the OAuth Client configuration page in the WP-PFManagement docs.

Supported grants

  • Authorization code — the interactive, user-consent flow (with PKCE where the provider supports it). The user is sent to the provider and returns to a callback at /wp-json/wp-pfworkflow/v1/oauth/callback; the issued token is stored on the connection.
  • Client credentials — the machine-to-machine grant, no user and no browser: Workflow posts the client id/secret to the token endpoint and gets an access token.
  • Refresh — expired access tokens are refreshed automatically and opportunistically before an outbound call, rotating the refresh token when the provider rotates it.

Tokens live only in Management

Every issued, refreshed or client-credentials token is written back to WP-PFManagement, which is the single store for OAuth tokens — Workflow keeps no local token copy. Management encrypts them at rest; Workflow reads the decrypted token in-process only for the moment it makes the call. (An OAuth-backed connection therefore requires Management to be active.)

SSRF protection

Every token-endpoint call goes through the same guard as the rest of the outbound stack: private, link-local and cloud-metadata addresses are refused before the request is sent, so a mis-configured or hostile token URL cannot be used to reach inside your network.