Any OAuth 2.0 provider
Custom OAuth flow
Bring any OAuth 2.0 or OpenID Connect provider. Detect its endpoints or enter them yourself, then run, verify, and export the flow.
Build your ownWorkflow guide
Check this setup link before using it
Someone shared these provider settings. When you run the flow, your client ID, client secret, codes, and tokens are sent to these hosts:
Step 3
Export the flow
Secrets are never included. The code reads them from environment variables, and the setup link carries only the provider settings.
Enter the provider settings to generate code.- 01DescribeDetect the endpoints from an issuer URL, or enter them yourself.
- 02AuthorizeOpen the provider’s consent screen; the callback returns here.
- 03ExchangeSwap the code for tokens using your client authentication method.
- 04VerifyCall a userinfo or test endpoint with the access token.
- 05ExportCopy the flow as code, or share the settings with a setup link.
What this workflow can do
- Detect endpoints from an issuer URL
- Build the authorization URL
- Exchange, refresh, and verify
- Export the flow as curl, Node, or Python
- Share settings with a setup link
Before starting
- An OAuth 2.0 app registered with the provider (client ID, and a secret unless it is a public client)
- The provider’s authorization and token endpoints, or an OpenID Connect issuer URL
- This page registered as a redirect URI
- Scopes your app is allowed to request
Result handling
- Tokens appear in the result panel and can be verified against any userinfo or introspection-style endpoint.
- Provider OAuth error codes such as invalid_grant are shown; raw provider responses are not.
- Settings, secrets, and tokens stay in this page only and are never stored.
Provider warnings
- Endpoints must be public https:// URLs. Private, internal, and redirecting endpoints are refused.
- Register this page as the redirect URI with your provider (it is pre-filled below).
Troubleshooting
- redirect_uri_mismatch: register exactly the redirect URI shown below, including https and any trailing slash.
- invalid_client: try the other client authentication method (Basic header vs request body). Providers usually accept only one.
- invalid_grant: authorization codes are single-use and short-lived. Authorize again and exchange straight away.
- unsupported_grant_type or invalid_request: some providers want a JSON body instead of form encoding.
- An endpoint that redirects is refused. Use the final URL the provider documents.
Provider checklist
- Detect or enter the authorization and token endpoints.
- Choose the client authentication method your provider documents.
- Generate a PKCE pair if the provider requires or supports it.
- Authorize, exchange, then verify the access token.
- Export the flow as code, or copy the setup link for a teammate.