OAuth2 Provider — Reference
Define the remote authorization/token endpoints and client credentials used by an OAuth flow.
Define the remote authorization/token endpoints and client credentials used by an OAuth flow.
Before you begin
Section titled “Before you begin”- A remote provider test application with registered callback URL and the permissions/grant appropriate to the integration. Keep credentials server-side.
OAuth2 Provider
Section titled “OAuth2 Provider”Define the remote authorization/token endpoints and client credentials used by an OAuth flow.
Settings
Section titled “Settings”| Setting | Meaning |
|---|---|
| Name | When editing the provider module, names the reusable definition. In an action, selects an existing OAuth provider file. |
| Type | The definition offers Client Secret or JWT. This chooses the credential/assertion setup, not whether the application user is locally logged in. |
| Service | Selects a preset endpoint configuration or Custom. Presets are shipped configuration, not a guarantee that every provider’s current requirements are covered. Check the saved service and endpoint values; the current Coinbase-labelled rule choice maps to the stripe value and must not be treated as a valid Coinbase preset. |
| JWT | Selects the JWT signing definition used for a JWT-bearer token grant. It is distinct from decoding an arbitrary incoming JWT. |
| Auth Endpoint | The remote authorization URL used to send a user through consent. Required for an interactive authorization-code flow when not supplied by the chosen preset. |
| Token Endpoint | The URL used by the server to exchange a grant for a token. Supply the provider’s current endpoint when using Custom. |
| Client Id | The identifier issued to the registered application. |
| Client Secret | The corresponding server-side secret where the grant requires it. Do not put it in page code or action output. |
| Token Handling | Session uses the runtime’s session token storage; Self Maintain exposes explicit Access Token and Refresh Token fields. This selection does not automatically create a database token-storage or rotation workflow. |
| Access Token | A supplied token for the remote API when managing tokens explicitly. It can expire or be revoked; selecting it does not validate it indefinitely. |
| Refresh Token | A supplied refresh token where the provider supports that grant. A provider may omit or rotate it; update your storage deliberately. |
| Scope Separator | The separator joining requested scopes. It depends on the remote service; a preset may supply its own value. |
| Use PKCE | The installed Node.js authorization flow implements an S256 challenge and stores the verifier in the session. The installed PHP OAuth helper does not implement the same PKCE branch, so do not assume that checking this control provides it on PHP. |
| Client Credentials | Requests a client-credentials grant for the application’s own access when supported by the remote provider. It is not a user-consent login flow. |
| Verify SSL | The PHP transport uses this option for certificate verification and defaults it on. The Node.js transport does not use the checkbox as a TLS override in the same way. |
| Params | Additional provider-specific authorization parameters. Do not casually override state, redirect URI or other security-critical defaults; verify the full request against the registered provider configuration. |
Verification example
Section titled “Verification example”Create a provider using the credentials and endpoints of a dedicated test application. Register the exact callback URL of the Server Connect action containing OAuth2 Authorize. Verify the authorization redirect, callback, token response and a permitted test API read. Test cancellation and expired tokens separately.
Flow boundaries
Section titled “Flow boundaries”The callback scheme, host and path must match the provider registration; proxy configuration affects how the runtime constructs it. An OAuth token authorizes a remote service operation and does not automatically create a local Security Provider session or link a local account. Confirm the current provider grant/PKCE requirements before choosing a runtime.
Use the token in the intended server call
Section titled “Use the token in the intended server call”Configure the outgoing API Action to use the authorized provider where appropriate. Verify its response and requested permissions before connecting data to the page.
Check your result
Section titled “Check your result”You can distinguish provider configuration, browser authorization, token exchange and local application authentication.