Third-party SaaS OAuth for agents

Inside one Microsoft Entra tenant, an MCP resource server can validate a user token minted for its own audience and exchange it on-behalf-of for a downstream internal API. Keep that audience validation and OBO exchange in the identity layer that owns those app registrations.

Slack, Google, GitHub, Stripe, HubSpot, and other third-party systems do not accept your internal OBO chain. They require separate provider consent and per-user grants. That cross-provider lifecycle is the problem Astrail is designed to operate.

The agent authenticates to Astrail with an Astrail API key scoped to an end user and actor role. Astrail rejects mismatched identity headers, requires that user's matching provider grant, and injects that decrypted token for the mapped upstream request. End-user OAuth calls never fall back to a workspace-wide provider identity.

A client-provided bearer token is never forwarded to a provider. This prevents one caller token from silently becoming every downstream identity and keeps provider credentials out of model context, browser storage, and logs.

Astrail derives OAuth authorization and token endpoints from the imported API contract and binds every grant to a fingerprint of that scheme, those endpoints, and the upstream API origin. Changing the provider or API origin requires a new connection instead of silently reusing an old token.

Known SaaS providers enforce approved OAuth hosts. For custom providers, the dashboard shows the exact authorization, token, and API origins and requires an explicit trust confirmation before Astrail accepts a client secret or starts consent.

Generated tools preserve operation-level OAuth scope requirements from the API contract. Before execution, Astrail compares those requirements with the scopes recorded on the selected end-user grant.

If no allowed OAuth alternative is satisfied, the provider token is withheld and the tool returns oauth_insufficient_scope with required_scopes and missing_scopes. The user can reconnect with the smallest additional consent needed instead of granting broad access by default.

Expired access tokens refresh server-side with a cross-instance lease so providers that rotate refresh tokens are not raced by concurrent tool calls. Permanent invalid_grant and invalid_client responses mark the connection reauth_required and stop repeated refresh attempts.

Removing a connection immediately prevents Astrail from injecting the stored credential again. If your threat model requires immediate invalidation at the provider too, revoke the grant through that provider's console or revocation API until a provider-specific revocation flow is configured.