User-passthrough integrations
Integrations
A user-passthrough integration forwards the actual end user’s identity to the upstream system via OAuth token exchange (RFC 8693). The upstream system enforces its own access controls against that user — row-level Snowflake grants, per-record Salesforce visibility — and Greenlight’s audit log records the call attribution.
Use this kind when the upstream system has meaningful per-user RBAC you want apps to respect. If a shared service account works, prefer the simpler service account integration instead.
How token exchange works
The data broker handles the OAuth flow on every request. The app does not implement any OAuth code.
- The app calls the broker with a request to a user-passthrough integration.
- The broker reads the user’s identity from the agent or end-user session it’s authenticating.
- The broker exchanges that identity for a user-scoped upstream token using the configured token-exchange endpoint of the upstream’s authorization server.
- The broker forwards the request with the user-scoped token.
- The upstream system applies its own RBAC against that user.
The exchange is cached per (user, integration) for the lifetime the upstream token issuer specifies. The app code is identical to a service-account integration; it just happens to be running as the bound user upstream.
Supported integrations
| Integration | Token exchange profile |
|---|---|
| Snowflake | Snowflake External OAuth |
| Salesforce | Salesforce OAuth 2.0 token exchange |
| Custom upstream | Any service that implements RFC 8693 against your IdP |
If the upstream has a non-standard exchange flow, IT can configure a custom oauth2_token_exchange profile that specifies the exchange endpoint, claims, and scope mapping.
What IT needs to configure
User-passthrough requires more setup than service account because the customer’s IdP and the upstream system both need to be configured to trust each other.
- Configure the upstream system to trust your identity provider as an external OAuth authorization server.
- In your IdP, enable token exchange and define the audience for the upstream.
- In Greenlight, register the integration as a user-passthrough kind and supply the token-exchange endpoint and audience.
- Grant the integration to apps that need it.
Once configured, the day-to-day operating experience is identical to a service account integration — IT grants it to apps; apps use the same proxy URL pattern; revocation is instant.
When the user has no upstream identity
If a request arrives at the broker for a user-passthrough integration and the user is not provisioned in the upstream system, the broker returns a structured error. Apps and agents handle this by surfacing a clear message rather than retrying. Provisioning the user in the upstream is the org’s responsibility — typically through SCIM or a one-time admin grant — and is out of Greenlight’s scope.