What this workflow can do

  • Build authorization URL
  • Exchange authorization code
  • Refresh token
  • Verify access token

Before starting

  • Client ID
  • Client secret optional
  • Redirect URI
  • Scopes
  • PKCE challenge and verifier
  • Callback code and state

Result handling

  • Access token returns from exchange and can be verified in the result panel.
  • Refresh token may return from exchange or refresh.
  • Callback state is only used to validate the current handshake.
  • Anonymous OAuth Hub workflows do not store client secrets, authorization codes, access tokens, or refresh tokens.

Provider warnings

  • X public clients use PKCE and can leave the client secret blank.
  1. 01PrepareEnter provider credentials, scopes, callback details, and PKCE values if required.
  2. 02AuthorizeBuild the authorization URL and open provider consent.
  3. 03ExchangePaste the returned code and state, then exchange them for tokens.
  4. 04VerifyTest the access token against the provider verification endpoint.
  5. 05Next stepsCopy tokens or metadata, then store them safely outside anonymous mode.

Credentials

OAuth handshake

Provider callback returns code and state. Refresh uses refresh_token.

This provider requires both PKCE fields.

Troubleshooting

  • X OAuth 2.0 often requires PKCE; provide code_challenge and code_verifier for reliable exchange.
  • Public X clients send client_id in the token request body without Basic authentication; confidential clients can still provide a client secret.
  • Ensure app permissions include selected scopes, especially offline.access for refresh tokens.