Repository navigation
design(providers): cloud-native auth for Azure AI Foundry (Entra ID) and Amazon Bedrock (SigV4 / IAM Identity Center) #6072
Description
Follow-up from #6031. The API-key connections for Azure AI Foundry and Amazon Bedrock (#6032) deliberately cover only key-based access. This issue tracks the cloud-native authentication those entries do not provide, which #860 left out of the initial provider scope because it needs its own product design.
Scope
- Azure AI Foundry: Microsoft Entra ID. Token acquisition and refresh, tenant/project selection, and how a Foundry project endpoint (rather than the
/openai/v1or/anthropicresource endpoint) is configured. - Amazon Bedrock: AWS credentials. SigV4 signing from the standard credential chain (profiles, environment, SSO cache), region selection, and IAM Identity Center sign-in.
- feat(provider): add Amazon Bedrock IAM Identity Center SSO #3370 (keyuchen21) proposed IAM Identity Center for Bedrock under the
amazon-bedrockprovider id with anaws_ssocredential kind. It was closed by the stale bot on 2026-10-07 for inactivity, not rejected. Reviving or rescoping it is the natural starting point. - The API-key entry from feat(providers): add Azure Foundry and Bedrock API-key connections #6032 uses a separate id,
amazon-bedrock-api-key, so it does not collide withamazon-bedrock.
- feat(provider): add Amazon Bedrock IAM Identity Center SSO #3370 (keyuchen21) proposed IAM Identity Center for Bedrock under the
Open design questions
- One provider entry per cloud with a credential-kind choice, or separate entries per auth method, given that feat(providers): add Azure Foundry and Bedrock API-key connections #6032 already ships an API-key entry?
- Where credentials and refresh live: Desktop main, the Runtime Host, or the CLI. This includes how a remote (SSH) Runtime Host gets them.
- What happens to an existing API-key connection if the same provider later gains a cloud-native credential kind (migration or coexistence)?
Activity
liugddx commentedon Oct 18, 2026
Here's a direction for the three open questions, based on how connections already work and on #3370.
1. Separate entries per auth method, not one entry with a credential-kind choice. Today each
providerTypehas exactly oneauthKind(providerDefaultsOf(...).authKind, whichderiveProviderAuthContractgates on), and #6032 already follows that rule withamazon-bedrock-api-key. Keeping it means:amazon-bedrockis IAM Identity Center / SigV4, as feat(provider): add Amazon Bedrock IAM Identity Center SSO #3370 proposed.azure-foundry-entra.2. Credentials and refresh live in the Runtime Host. OAuth subscriptions already work this way, and #3370 used the same pattern for Bedrock:
Device authorization also answers the remote (SSH) Host case, because the user can complete sign-in on any machine. Reading
~/.awsor environment credentials should be an explicit option on the Host side, reading the credential chain of the machine the Host runs on, never the client's.3. Coexistence, no migration. Because the ids differ, an existing API-key connection keeps working unchanged next to a new cloud-native one. Users switch by adding the new connection. We can add a hint on the API-key entry later if we want to steer people.
Suggested order:
ConverseStreamevidence. It needs a rebase and a fresh epoch.@keyuchen21, are you interested in picking #3370 back up? If not, it's open for anyone.
keyuchen21 commentedon Oct 18, 2026
@liugddx I will give it a try
youlemei2022-web commentedon Oct 20, 2026
Thanks @keyuchen21 — go ahead. Keep it to the design first (separate
azure-foundry-entraentry, Host-owned device flow + refresh, short-lived role credentials never leaving the Host), and open it as a draft so we can review the contract before implementation.docs(providers): narrow cloud-native auth design to Bedrock
keyuchen21 commentedon Oct 24, 2026
@liugddx @youlemei2022-web Opened the design as a draft: #6277.
It covers
amazon-bedrock(IAM Identity Center → SigV4) only and keeps the shared decisions from this thread: separate entries per auth method, Host-owned device flow and refresh, and role credentials that never leave Host memory. The review findings from #3370 are written as invariants I1–I13, each with a required regression test.azure-foundry-entrais left as a follow-up that can reuse the same contract (§10).Two questions for you (§11):
~/.awson the Host machine) be in the first release, or later?cloud_identity.*operation family, orbedrock.sso.*as in feat(provider): add Amazon Bedrock IAM Identity Center SSO #3370?docs(providers): add Bedrock SSO trust-boundary diagram
keyuchen21 commentedon Oct 24, 2026
Trust-boundary diagram for the Bedrock design in #6277 (also embedded in §4 of the document):
configuration.credentials.exportrejectscloud_identity_session(I7).0600, atomic) and the one canonicalamazon-bedrockcatalog entry (I8).