feat: add AWS SigV4 proxy integration

[nickvelloff]

Summary

• introduce the AWS SigV4 provider (docs, spec entry, logo, generated templates, and connect UI copy) so customers can create proxy integrations against AWS services
• add the SigV4 auth flow on the backend (new /auth/aws-sigv4 controller, session/reconnect handling, validation, and reconnect defaults) plus expose the new auth type through the shared types & SDKs
• add the signing/proxy helpers (shared proxy service + unit tests) and hook them into the connection service so signed calls pick up the correct base URL and ARN context

Testing

• npm run test packages/shared/lib/services/proxy/aws-sigv4.unit.test.ts
• npm run test packages/server/test/integration/connect/postReconnect.integration.test.ts
• npm run test packages/server/test/integration/providerConfigKey/patchIntegration.integration.test.ts

---

Add Universal AWS SigV4 Proxy Provider With Full Backend, SDK, and UI Support

This PR introduces a new first-class “AWS SigV4” provider that enables any AWS service to be called through an automatically signed proxy. It spans backend authentication flow, request signing and proxying, type propagation across all SDKs, UI updates, documentation, and extensive tests. The change is backward-compatible but adds a new AuthType enum value that consumers must adopt to leverage the feature.

Key Changes

• Introduced 'aws-sigv4' provider entry in providers.yaml and OpenAPI spec
• Implemented /auth/aws-sigv4 controller for session creation, reconnect, and validation
• Added shared proxy service (aws-sigv4.ts) that builds canonical requests and injects SigV4 headers
• Propagated new AuthType through shared/types, backend, Node client, runner-sdk, and frontend
• Updated Connect UI to surface AWS-specific inputs (region, service, role ARN, externalId, etc.)
• Extended docs, codegen templates, and SDK samples to cover the new provider
• Added unit and integration tests for signing logic, session endpoints, and provider validation

Affected Areas

• Auth controllers (/auth/aws-sigv4)
• Shared proxy/service layer
• Type definitions & SDKs (@types/api, node-client, runner-sdk)
• Webapp / Connect UI
• Docs & generated samples
• Provider validation schema and script
• CI test suites

---

This summary was automatically generated by @propel-code-bot

[propel-code-bot]

[Documentation]

Fix spelling: change "Pre-Requisites" to "Prerequisites".

Context for Agents

[**Documentation**]

Fix spelling: change "Pre-Requisites" to "Prerequisites".

File: docs/integrations/all/aws-sigv4.mdx
Line: 18

[propel-code-bot]

[Documentation]

Fix typo: "End-to-type type safety" should be "End-to-end type safety".

Context for Agents

[**Documentation**]

Fix typo: "End-to-type type safety" should be "End-to-end type safety".

File: docs/snippets/generated/aws-sigv4/PreBuiltTooling.mdx
Line: 26

[propel-code-bot]

[Documentation]

Add a newline at the end of the file to avoid the “No newline at end of file” marker.

Context for Agents

[**Documentation**]

Add a newline at the end of the file to avoid the “No newline at end of file” marker.

File: docs/snippets/generated/aws-sigv4/PreBuiltTooling.mdx
Line: 40

[TBonnin]

A few questions:

• who is running/providing the STS helper service?
• can you share the cloudformation template?

[khaliqgant]

• who is running/providing the STS helper service?

Our users would have to run the STS helper service

[TBonnin]

• who is running/providing the STS helper service?

Our users would have to run the STS helper service

With some cross-account sts assume role policy I imagine. I guess that what the cloudformation template is setting up. I would like to see the intended template.

[nickvelloff]

The intent is that the Nango customer runs their own STS helper container in their AWS account; it assumes roles on behalf of their end customers. That keeps Nango out of operating that lifecycle and cleanly separates responsibilities.

Nango could optionally “provide” a boilerplate service, but only as a contract/example (see https://github.com/nickvelloff/nango-sts-boilerplate). It’s deliberately simple.

CloudFormation templates are owned/hosted by the customer because they reflect their specific role needs. The only requirement is that the template URL is publicly readable (CORS-friendly) so the UI can hydrate parameters. Nango could host a few generic templates as defaults, but that’s just a nice-to-have. We assume anyone needing this enterprise-style integration already has the CloudFormation/DevOps maturity to host their own templates.

Cloudformation template example (https://raw.githubusercontent.com/nickvelloff/nango-sts-boilerplate/refs/heads/main/infra/cloudformation/s3-readonly.json) - simply hosted publicly.

Importantly: This file explains the usage and validation flows a customer would want to leverage when setting this up - https://github.com/nickvelloff/nango-sts-boilerplate/blob/main/docs/aws-sigv4-e2e-validation.md