Skip to main content

OAuth Connections

OAuth connections let you log in to external services once and then reuse that connection in any agent or integration.
This means no more re-entering keys or secrets in every component. You configure it once and select it whenever you need it.

Why this matters

Instead of setting up Google, LinkedIn, or Twitter credentials over and over, SmythOS stores them securely in your Vault. Next time you build an agent, you simply pick the saved connection.

Step 1: Open the Vault​

Go to the Vault and scroll to OAuth Connections under Enterprise Models.

Vault page showing OAuth Connections section

Step 2: Add a New OAuth Connection​

Click Add OAuth Connection and a setup window will open.

Add OAuth Connection modal

Use the Select Provider dropdown to choose the service you want to connect to:

  • Google — Connect to Google services using OAuth 2.0.
  • LinkedIn — Connect to LinkedIn using OAuth 2.0.
  • X (OAuth 1.0a) — Connect to Twitter using OAuth 1.0a.
  • X (OAuth 2.0) — Connect to Twitter/X using OAuth 2.0 with PKCE.
  • Custom OAuth 2.0 — Connect to any service using a custom OAuth 2.0 configuration.
  • Custom OAuth 1.0 — Connect to any service using a custom OAuth 1.0a configuration.
  • OAuth2 Client Credentials — For server-to-server flows that don’t involve user login.

Once you select a provider, the form updates to show the fields required for that connection type.

Step 3: Fill in the Details​

Legacy connections

Connections created before Vault show a Legacy badge.
They still work, but add new ones here for consistency.

Each service type asks for slightly different information. Here’s what you’ll see and how to complete it.

Google, LinkedIn, Twitter (Prefilled Services)​

If you choose one of these, SmythOS already knows the right URLs.
You’ll only need to provide:

Google OAuth example

Custom OAuth 2.0​

For any service that supports OAuth 2.0 but isn’t prefilled:

Custom OAuth 2.0 example
  • Authorization URL — where users are redirected to log in (from your provider’s docs).
  • Token URL — where SmythOS exchanges the authorization code for a token.
  • Client ID / Client Secret — from your provider’s developer settings.
  • Scopes — space-separated list of permissions (check your provider’s API docs).
  • Callback Path — pre-filled by SmythOS (https://app.smythos.dev/oauth/oauth2/callback). Copy this into your provider’s allowed redirect URIs.
  • Enable PKCE — adds Proof Key for Code Exchange to the OAuth flow (see below).

Enable PKCE​

PKCE (Proof Key for Code Exchange) is a security extension for OAuth 2.0 that protects the authorization code from interception. Some providers require it; others recommend it for public clients.

When you toggle Enable PKCE on, SmythOS automatically:

  1. Generates a code_verifier and derives a code_challenge from it.
  2. Includes code_challenge and code_challenge_method=S256 in the authorization request sent to the provider.
  3. Sends the code_verifier when exchanging the authorization code for a token.

You do not need to provide any additional fields — PKCE is handled entirely by SmythOS once the toggle is on.

When to enable PKCE

Enable PKCE if your provider’s docs mention it as required or recommended, or if you’re seeing authorization errors with standard Custom OAuth 2.0 flows. Existing connections without PKCE are unaffected.

OAuth2 Client Credentials​

For services that don’t involve user login (server-to-server APIs):

  • Token URL — usually listed in the provider’s API documentation.
  • Client ID / Client Secret — provided when you create an app in the provider’s console.

Tip: Use this if the API doesn’t involve a person logging in, only a system.

OAuth 1.0 (Legacy)​

Some older APIs still use OAuth1.0.

You’ll need to provide:

  • Request Token URL — to get a temporary token.
  • Access Token URL — to exchange it for an access token.
  • User Auth URL — where users approve the request.
  • Consumer Key / Consumer Secret — from your provider’s developer settings.
  • Callback URL — pre-filled by SmythOS, add it to your provider’s settings.

Step 4: Save and Authenticate​

Click Add Connection.
If the provider requires user login, you’ll be redirected to approve the connection.

Once done, the connection appears in your Vault. From there you can:

  • Authenticate / Sign out
  • Edit details
  • Duplicate a setup
  • Remove it

Step 5: Use in a Component​

When you add an API call or integration, expand the OAuth section.

OAuth dropdown in a component
  • If you already have Vault connections, you’ll see them in the dropdown.
  • If a connection was created before Vault existed, it shows with a Legacy badge.
  • If nothing is set up yet, click + Add New and follow the same steps without leaving the component. \

Then just click Authenticate, and your component is ready to go.

Example Workflow​

  • You go to the Vault and create a Google OAuth connection with Gmail scopes.
  • A teammate later builds a new workflow and selects that connection in their component.
  • Neither of you needs to reconfigure anything since the same saved connection works for both.