Signing in to Microsoft Foundry from OpenClaw using Azure AD: a smoother way to bring your models in
This post is a quick update to walk through the new flow. If you read the previous one, think of this as the easier path I wish I had the first time round. If you have not seen the original, you can find it here: Integrating Microsoft Foundry with OpenClaw: Step by Step Model Configuration | Microsoft Community Hub Pre-requisite: You will need the Azure CLI (azure-cli) installed on your machine. The official install guide for Linux is here: https://learn.microsoft.com/en-us/cli/azure/install-azure-cli-linux?view=azure-cli-latest I am on Linux so I went the Homebrew route, which keeps things simple. The formula is here: https://formulae.brew.sh/formula/azure-cli Microsoft also has official docs covering the Homebrew/Linuxbrew install: https://learn.microsoft.com/en-us/cli/azure/install-azure-cli-macos?view=azure-cli-latest#install-with-homebrew Once Homebrew is ready, run this in your terminal: brew install azure-cli Why this matters: Before this update, every Foundry model you wanted to use in OpenClaw needed its own API key and endpoint pasted into the config. It worked, but it was tedious, and keys are easy to leak if you are copying them around. The Azure AD path solves both problems. You authenticate as yourself (or a service principal), OpenClaw asks Azure for the list of Foundry resources you have access to, and it brings the models in automatically. Signing in to Microsoft Foundry from OpenClaw via Azure AD A device-code OAuth handshake replaces the old static-API-key flow. OpenClaw delegates auth to the local Azure CLI; the CLI handles the browser-side sign-in, holds the resulting tokens, and refreshes them silently. OpenClaw then walks the Azure resource graph, subscriptions → Foundry resources → model deployments and registers each model into its own config. No API keys move through OpenClaw at any point. Sequence diagram of the OAuth 2.0 device-authorization flow as orchestrated by OpenClaw. Phases 1–3 establish identity (the developer authenticates once, in a real browser, against Azure AD). Phases 4–5 perform service discovery (OpenClaw walks the ARM resource hierarchy, subscriptions → Foundry accounts → model deployments and persists the result to a local provider config). After registration, every model call OpenClaw makes against Foundry reuses the same Azure-CLI-managed token cache: tokens refresh transparently, and access is gated by the Foundry resource's RBAC assignments rather than a static API key. Dashed lines denote return values; the teal line in step 7 marks the single token-issuance event the rest of the system pivots on. Walking through the new flow: Start with the command to onboard openclaw as if you were setting up OpenClaw for the first time: openclaw onboard Kick things off with the OpenClaw onboard command, the same one you would use when setting up OpenClaw for the first time. When it prompts you, choose update values. Next, you will be asked to configure your models. Scroll down a little and you will see Microsoft Foundry listed as a supported provider. Pick it. From here, you have two options. You can sign in with an API key, which is what I covered in the previous blog post, or you can sign in through Azure AD. The Azure AD path is easier and more secure, so that is the one we will use. OpenClaw will give you a URL and a device code. Copy the URL into your browser and use the code to complete the sign in. (This is where the az CLI from the pre-requisite section earns its keep.) If everything worked, you should see a success prompt similar to this: Once you are signed in, OpenClaw will ask you to pick the Azure subscription that your Microsoft Foundry resource lives in. Pick the subscription, then pick the Foundry resource where your models are deployed. And that is pretty much it. All the models you have deployed to that Foundry resource get pulled into OpenClaw automatically. Compared to the old way of pasting API keys and endpoints one by one, this is a huge time saver, and you do not have to babysit any keys. From here you can start using your Foundry-deployed models inside OpenClaw straight away: Wrapping up The Azure AD sign-in option in OpenClaw is one of those small updates that quietly removes a real pain point. If you have ever juggled multiple Foundry endpoints and rotated keys across them, you already know why. With this flow, you sign in once, your models show up, and you can get back to actually building. If you have not tried OpenClaw with Microsoft Foundry yet, this is a good time to give it a go. And if you were holding off because of the key management overhead, that excuse is gone now. References Previous post on integrating Microsoft Foundry with OpenClaw using API keys: Integrating Microsoft Foundry with OpenClaw: Step by Step Model Configuration | Microsoft Community Hub Install the Azure CLI on Linux: https://learn.microsoft.com/en-us/cli/azure/install-azure-cli-linux?view=azure-cli-latest Install the Azure CLI on macOS: https://learn.microsoft.com/en-us/cli/azure/install-azure-cli-macos?view=azure-cli-latest#install-with-homebrew Homebrew formula for azure-cli: https://formulae.brew.sh/formula/azure-cliHow to use DefaultAzureCredential across multiple tenants
If you are using the DefaultAzureCredential class from the Azure Identity SDK while your user account is associated with multiple tenants, you may find yourself frequently running into API authentication errors (such as HTTP 401/Unauthorized). This post is for you! These are your two options for successful authentication from a non-default tenant: Setup your environment precisely to force DefaultAzureCredential to use the desired tenant Use a specific credential class and explicitly pass in the desired tenant ID Option 1: Get DefaultAzureCredential working The DefaultAzureCredential class is a credential chain, which means that it tries a sequence of credential classes until it finds one that can authenticate successfully. The current sequence is: EnvironmentCredential WorkloadIdentityCredential ManagedIdentityCredential SharedTokenCacheCredential AzureCliCredential AzurePowerShellCredential AzureDeveloperCliCredential InteractiveBrowserCredential For example, on my personal machine, only two of those credentials can retrieve tokens: AzureCliCredential : from logging in with Azure CLI ( az login ) AzureDeveloperCliCredential : from logging in with Azure Developer CLI ( azd auth login ) Many developers are logged in with those two credentials, so it's crucial to understand how this chained credential works. The AzureCliCredential is earlier in the chain, so if you are logged in with that, you must have the desired tenant set as the "active tenant". According to Azure CLI documentation, there are two ways to set the active tenant: az account set --subscription SUBSCRIPTION-ID where the subscription is from the desired tenant az login --tenant TENANT-ID , with no subsequent az login commands after Whatever option you choose, you can confirm that your desired tenant is currently the default by running az account show and verifying the tenantId in the account details shown. If you are only logged in with the azd CLI and not the Azure CLI, you have a problem: the azd cli does not currently have a way to set the active tenant. If that credential is called with no additional information, azd assumes your home tenant, which may not be desired. The azd credential does check for a system variable called AZURE_TENANT_ID , however, so you can try setting that in your environment before running code that uses DefaultAzureCredential . That should work as long as the DefaultAzureCredential code is truly running in the same environment where AZURE_TENANT_ID has been set. Option 2: Use specific credentials For this second option, we will abandon DefaultAzureCredential entirely, and replace it with specific credential classes. This approach requires a code change, but once you've gone through the effort to set it up, it's generally a more predictable experience. Use CLI credential for local dev Several of the credential classes allow you to explicitly pass in a tenant ID, including both the AzureCliCredential and AzureDeveloperCliCredential . If you know that you’re always going to be logging in with a specific CLI, you can change your code to that credential: For example, in the Python SDK: AzureDeveloperCliCredential(tenant_id=os.environ["AZURE_TENANT_ID"]) For more flexibility, you can use conditionals to only pass in a tenant ID if one is set in the environment: if AZURE_TENANT_ID := os.environ("AZURE_TENANT_ID"): cred = AzureDeveloperCliCredential(tenant_id=AZURE_TENANT_ID) else: cred = AzureDeveloperCliCredential() 💁🏼♀️ Tip: As a best practice, I always like to add logging statements that note exactly what credential I'm calling and whether I'm passing in a tenant ID, to help me spot misconfigurations from the logs. Use managed identity credential in production You must be careful when replacing DefaultAzureCredential if our code will also be deployed to a production host. In that case, your code was previously relying on DefaultAzureCredential using the ManagedIdentityCredential in the chain, and you now need to call that credential class directly. You will also need to pass in the managed identity client ID, if your host is using user-assigned identity instead of system-assigned identity. For example, using managed identity in the Python SDK with user-assigned identity: ManagedIdentityCredential(client_id=os.environ["AZURE_CLIENT_ID"]) Here’s a full credential setup for an app that works locally with azd and works in production with managed identity (either system or user-assigned): if RUNNING_ON_AZURE: if AZURE_CLIENT_ID := os.getenv("AZURE_CLIENT_ID"): cred = ManagedIdentityCredential(client_id=AZURE_CLIENT_ID) else: cred = ManagedIdentityCredential() elif AZURE_TENANT_ID := os.getenv("AZURE_TENANT_ID"): cred = AzureDeveloperCliCredential(tenant_id=AZURE_TENANT_ID) else: cred = AzureDeveloperCliCredential() For a full walkthrough of an end-to-end template that uses keyless auth in multiple languages, check out my colleague's tutorials on using keyless auth in AI apps.Unlock the Future of Secure Authentication: Moving to Keyless Authentication with Managed Identity
Why Managed Identity? Traditional authentication methods often rely on keys, secrets, and passwords that can be easily compromised. Managed identity, on the other hand, provides a secure and seamless way to authenticate without the need for managing credentials. By leveraging managed identity, you can: Reduce the Risk of Compromise: As most security breaches start from identity-related issues, moving to a keyless authentication system significantly reduces the chances of such compromises. Simplify Credential Management: Managed identity eliminates the need for managing keys and secrets, making the authentication process more straightforward and less error-prone. Enhance Security: With managed identity, your applications are granted access to resources securely, without the risk of exposing sensitive credentials. Getting Started with Managed Identity To help you get started with managed identity, Microsoft offers comprehensive training modules for different programming languages. These modules cover the basics of using managed identity to authenticate to Azure OpenAI, providing you with the knowledge and skills needed to implement secure authentication in your applications. Available Microsoft Learn Training Modules: Introduction to using Managed Identity to authenticate to Azure OpenAI with .NET - Training | Microsoft Learn Introduction to Azure OpenAI Managed Identity Authentication with Java - Training | Microsoft Learn Introduction to Azure OpenAI Managed Identity Authentication with Python - Training | Microsoft Learn Introduction to Azure OpenAI Managed Identity Authentication with JavaScript - Training | Microsoft Learn Why Should Students Learn Managed Identity? As a student, learning about managed identity and keyless authentication is not just about enhancing your technical skills; it's about preparing for the future. Here are a few reasons why you should dive into managed identity: Stay Ahead in the Job Market: With cybersecurity being a top priority for organizations, having expertise in secure authentication methods like managed identity will make you a valuable asset to potential employers. Build Secure Applications: By implementing managed identity, you can build applications that are more secure, reliable, and less susceptible to breaches. Understand Modern Security Practices: Gaining knowledge about managed identity and keyless authentication will give you a deeper understanding of modern security practices and how to protect applications in today's digital landscape. Conclusion In conclusion, moving to keyless authentication through managed identity is a game-changer for securing applications. As students and future developers, embracing this technology will not only enhance your skills but also contribute to building a safer and more secure digital world. So, take the first step today by exploring the training modules and mastering the art of managed identity!How to integrate Microsoft User Authentication using Microsoft Entra ID: A Step-by-Step Guide to Use
Microsoft Entra ID, also known as Azure AD (Active Directory), offers numerous advantages. Whether you're prioritizing security or seeking a well-organized and automated User Management system, this tool is your go-to for building a secure authentication system, be it for a web app, mobile app, or any other application.Revolutionize Your Student Project App Authentication with a PowerApps Login App Sample
Meet Seth Addo, a Gold Microsoft Learn Student Ambassador and Computer Science student at the University of Cape Coast, Ghana. Seth has developed a fantastic PowerApps app sample for performing basic authentication in a Power Platform application. In this app, users can enter their login credentials, which are compared with a table containing usernames and passwords. If the entered credentials match, users are granted access to a protected area of the application. This approach can be extended with additional functionality like password reset and multi-factor authentication to enhance application security. Try the PowerApps Login app today for a simple and secure way to log into your applications.
