OAuth2 Authorize — Reference
Start or complete the provider’s interactive authorization-code flow.
Start or complete the provider’s interactive authorization-code 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 Authorize
Section titled “OAuth2 Authorize”Start or complete the provider’s interactive authorization-code flow.
Settings
Section titled “Settings”| Setting | Meaning |
|---|---|
| Name | Names the returned grant response on a successful callback. The initial call normally redirects instead of immediately returning token data. |
| Output | Can expose the token/grant result in the action response. The rule initializes this on; disable it when tokens must remain server-side rather than being returned to the page. |
| Provider | The configured OAuth2 provider defining endpoints and client credentials. |
| Scopes | The requested permissions supported by the remote service. They are joined using the provider’s scope separator; they are not Wappler role names. |
| Params | Additional authorization parameters for the selected provider. The runtime generates and checks state using the browser session; overriding state or redirect parameters requires deliberate review. |
Verification example
Section titled “Verification example”Navigate a test browser to the authorization action. Confirm that it redirects to the intended provider. Complete or cancel the test consent flow and return to the same registered callback with the same session. On success, inspect server-side token availability through a permitted API call rather than exposing secrets to the page.
Flow boundaries
Section titled “Flow boundaries”A missing or changed session can prevent the callback state from matching and restart authorization. The installed runtime stores returned access/refresh tokens and expiry in session state where available. Refresh-token issuance and provider consent are service-specific. This step does not automatically implement local account registration, logout or record-level permissions.
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.