Connections and security

OneSchema connects to your external systems through connections: reusable configuration entries that live on the Settings → Connections page in your organization. Each connection is created once, secured with the appropriate credentials, and then attached to any number of Multi FileFeeds.

This page is a directory of every connection type, what it's for, and where to read more.

SFTP connections

Used for both SFTP sources (pulling files from a partner's SFTP server on a schedule) and SFTP destinations (delivering validated files to an SFTP server).

You provide:

  • Hostname and port.
  • Username.
  • Either a password or an SSH private key.
  • An optional path to scope reads/writes inside the server.

OneSchema validates the credentials when you save the connection. After that it's available in any MFF as a source or destination.

S3 connections

Used for two distinct flows:

Both use a cross-account IAM role with a trust policy that allows OneSchema's intermediate role to assume it via STS. You configure the role once and attach it to as many MFFs as you like.

Google Cloud Storage connections

Used for both GCS sources (reading files from your GCS bucket into an MFF import) and GCS destinations (writing validated output files to your bucket).

GCS connections use service-account impersonation: you grant a OneSchema-provided service account permission to impersonate a service account in your project, scoped to the buckets and prefixes you specify. OneSchema never holds long-lived GCP credentials — each MFF run gets short-lived impersonated tokens.

AWS Secrets Manager

Stores decryption keys, passphrases, and other sensitive material in your own AWS account; OneSchema retrieves the secret at runtime when a transform needs it. Today this powers the Decrypt files transform; future transforms that need runtime secrets will use the same plumbing.

Highlights:

  • OneSchema never stores the secret; it's fetched from your account on every read.
  • Short-lived STS credentials with a configurable session duration (we recommend 1 hour, the AWS default for AssumeRole).
  • Per-secret access: your IAM role only grants OneSchema what it needs.

See Configuring an AWS Secrets Manager Connection for the role and trust-policy setup.

Azure Key Vault

The Azure equivalent of the AWS Secrets Manager connection. Same runtime model: OneSchema fetches secrets at runtime via an App Registration in your Azure tenant, no sensitive material stored on the OneSchema side.

See Configuring an Azure Key Vault Connection for the App Registration and RBAC setup.

Google Sheets connection

Authenticates OneSchema to read from Google Sheets in your Google account. Used by the Google Sheets fetch source.

Connect a Google account once on the Settings → Connections page; OAuth scopes are scoped to read-only access on the spreadsheets you explicitly share.

Microsoft 365 (SharePoint / OneDrive) connection

Authenticates OneSchema to read from and write to SharePoint document libraries and OneDrive for Business drives. Used by Multi FileFeed Microsoft 365 sources and Microsoft 365 destinations, as well as the older Azure SharePoint fetch flowgraph node.

OneSchema uses delegated OAuth with the Sites.Selected scope:

  • A user in your organization signs in to Microsoft once and grants OneSchema a refresh token. OneSchema stores the per-user token and uses it to call Microsoft Graph on the user's behalf.
  • The OneSchema FileFeeds Connection app has no access to any SharePoint site by default. A tenant admin explicitly allowlists each site OneSchema may use via POST /sites/{id}/permissions. Your security team can audit which sites the app can read by listing those grants.
  • OneDrive for Business is per-user and doesn't require a site-level allowlist — the user's own delegated token covers their own OneDrive.

OneDrive Personal (the consumer product, separate from OneDrive for Business) is not supported.

See Connect Multi FileFeeds to Microsoft 365 (SharePoint / OneDrive) for the one-time admin consent + per-site allowlist setup and the user-side OAuth flow.

Event webhook authentication

Event webhooks (the notification channel that fires when an MFF import succeeds or fails) aren't a connection in the same sense as the above — they're configured per-org under Settings → Event webhooks — but they share the same security concerns. OneSchema supports:

  • Shared-secret authentication. You set a secret on the webhook configuration; OneSchema includes it on every delivery via the Authorization: Basic header, so your endpoint can reject any request that doesn't match.
  • Environment-scoped URLs and secrets. The webhook URL and secret can reference environment variables, so the same MFF can target different endpoints in Production, Staging, and Development without separate webhook configs.

See Using Event Webhooks for setup.

Permissions and roles

Creating or modifying connections requires the Admin role in your OneSchema organization. Once a connection is set up, Developer users can attach it to MFFs without needing connection-management permissions of their own.

Security posture

A few principles that apply across every connection type:

  • Credentials are never logged. OneSchema redacts API keys, passwords, SSH keys, and secret values throughout the platform.
  • Least privilege. Each connection's IAM role, App Registration, or service account should grant only the access OneSchema needs.
  • Short-lived credentials where supported. AWS connections use STS-issued short-lived credentials; Azure connections use OAuth client credentials with rotation reminders.
  • Audit trail. Every secret read and every connection use is recorded in the run view.

For broader security guidance (SOC 2, HIPAA, data residency), see the Security category.