[Feature] Support for OAuth/OIDC and SAML-based authentication

[therangerangler]

Summary

Add support for OAuth/OIDC and SAML-based authentication so that remote freelancers and external collaborators can access S3 buckets through their existing identity provider (IdP) — without needing to install the AWS CLI or manage long-term AWS credentials.

Background

Today, File Mover Express authenticates with AWS exclusively through named AWS CLI profiles (config.WithSharedConfigProfile). This works well for internal teams who already have the AWS CLI set up, but creates a significant barrier for external users such as freelancers or contractors:

• They must install and configure the AWS CLI
• They need long-term AWS credentials (access key + secret) issued and managed by the customer
• Rotating or revoking access requires credential management on both sides
• There is no way to leverage an existing corporate IdP (Google Workspace, Okta, Azure AD, etc.)

The AWS SDK v2 supports AssumeRoleWithWebIdentity and AssumeRoleWithSAML natively, which would allow File Mover Express to exchange an identity token from an existing IdP for temporary AWS credentials — no AWS CLI required.

Proposed priorities

Priority 1 — AssumeRoleWithWebIdentity (OAuth/OIDC)

The user authenticates with their existing IdP (Google, Okta, Azure AD, etc.) and receives a web identity token. File Mover Express exchanges this token for temporary AWS credentials via STS AssumeRoleWithWebIdentity. This is the most broadly useful option as it works with any OIDC-compliant IdP.

Priority 2 — AssumeRoleWithSAML

For organisations using SAML-based identity providers (common in enterprise environments), File Mover Express would accept a SAML assertion and exchange it for temporary credentials via STS AssumeRoleWithSAML.

What this looks like for users

Instead of configuring an AWS named profile, a user would configure their transfer profile with an IdP token source:

protocols:
  s3:
    transfer_profiles:
      - name: "freelancer-profile"
        bucket: "my-production-bucket"
        region: "us-east-1"
        auth:
          type: "web_identity"
          role_arn: "arn:aws:iam::123456789:role/FreelancerRole"
          token_file: "/path/to/oidc-token"   # or fetched interactively

The customer sets up an IAM role with a trust policy scoped to the IdP and shares the role ARN with the freelancer. The freelancer never sees an AWS access key.

Implementation notes

• All credential loading goes through GetSession in src/cli/core/transfer-api/s3_manager.go, which calls config.LoadDefaultConfig with WithSharedConfigProfile. This is the single integration point — a new auth type in the transfer profile config would select a different credential provider here.
• The AWS SDK v2 already includes stscreds.NewWebIdentityRoleProvider and stscreds.NewSAMLRoleProvider — no new dependencies needed.
• The session cache in GetSession (keyed by region-profile) would need to accommodate the new auth types as cache keys.
• Token refresh should be handled transparently — STS temporary credentials expire and need to be renewed during long transfers.

Relevant files

• src/cli/core/transfer-api/s3_manager.go — GetSession and loadDefaultConfig, the credential loading integration point
• src/cli/types/configtypes/config.go — TransferProfile struct, would need a new Auth field
• docs/Configuration.md — would need new auth configuration options documented
• docs/Setup.md — would need IAM trust policy setup documented for IdP-based access

Acceptance criteria

• Users can authenticate using an OIDC token in place of an AWS named profile
• SAML-based authentication is supported as a secondary option
• Temporary credentials are refreshed automatically during long-running transfers
• Existing named profile authentication is unaffected
• Setup documentation covers the required IAM trust policy configuration
• No requirement for the AWS CLI to be installed on the end user's machine