If you’ve been reading this blog over the years, you’ve watched me wrestle with bot identity in real time. Back in 2017 I built the SPAdminBot with a client ID, a client secret, and a lot of trust that nobody would accidentally commit those credentials to GitHub. Then in 2020 I wrote about stopping the use of client secrets and moving to Managed Identities. That was a genuine improvement. But I always had this nagging feeling that we were bolting identity onto bots as an afterthought, shoehorning agents into an authentication model designed for web apps and background services. At Ignite in November 2025, Microsoft announced Entra Agent ID, and for the first time it feels like agents are getting identity that was actually designed for them.

Back in 2020 I wrote about CI/CD for Teams apps with Azure DevOps. In that post I stored a username, password, and appId as pipeline variables. That was perfectly fine at the time. Everybody did it that way, and it worked. But if I’m being honest, every time I set up a new pipeline like that I got a little uncomfortable. Secrets sitting in a variables tab, protected by a lock icon and a prayer. We can do better now.

Microsoft announced on August 29, 2025 that both the Microsoft Graph CLI (mgc) and the Microsoft Graph Toolkit are being retired. The full shutdown is planned for August 28, 2026. If you’ve been relying on mgc commands in your automation scripts or CI/CD pipeline steps, you’ll need to find an alternative. I’ve been using these tools myself, and before that I was using the O365 CLI (now called CLI for Microsoft 365) in my CI/CD pipeline for Teams apps, which I wrote about in my CI/CD for Teams post. So when I saw this announcement, I immediately started looking at what to move to. Let’s get started.

So you are building an application. When following most of the guidelines you find online they will tell you that you will need to use an Azure AD App Registration. This Azure App registration will provide you access to an Office 365 service like the Microsoft Graph, SharePoint, Exchange,… This can either be delegated or application permissions. This post is about application permissions.

These are the default Service Principals installed in a new Tenant.

When quickly creating a bot channels registration in Azure (I usually do this for testing something) You can select to create your own Microsoft App ID and Secret. If you do this then you can copy/paste them because you need them later on. But when you select “Auto create App ID and Secret” they don’t show you the secret in your bot settings.

This post was stuck in my drafts folder for some time. I was doubting to post it because Richard diZerega has found a way better way to do the same thing. But I thought why not post it. There are always lots of ways to get the same result in development. I find his way better actually because I think my approach would have security issues.

Context

A while ago I read a blog post from Stéphane Eyskens who is a Microsoft MVP about authenticating a bot with ADAL so that you could call the Microsoft Graph with the token of the user in your bot. This then could be leveraged to get for instance the information or, as he uses in his blog, get the profile picture of the user talking to the bot. There is already a GitHub project for authenticating with the bot framework called the AuthBot but this includes a pop-up and copy pasting of code. As Stéphane also points out, in an enterprise context this is not something the end users are waiting for. They have to login enough into multiple systems on a regular working day. Now while playing around with the Bot framework and the webchat control I found out that the webchat control is actually open sourced. They made the code available on GitHub. So looking at this I noticed that, while Stéphane proposes a solution that incorporates a proxy, I found an alternative way of doing this. This way is more focused on incorporating the webchat into SharePoint Online and have contextual authentication.

While researching my presentation on the Azure Container Service I came up with the idea to see what people where tweeting about the conference I was going to attend. Now for this I don’t even need to write code. The app in my phone can do this. But what other data is available from the Twitter API and to take it even further. Why not let the Microsoft Cognitive Services examine people’s profile, background and tweeted pictures. Just to show how many data is available about somebody and that we can monitor the data the conference generates. These series of blog posts will explain how I got things working and how this code will evolve over time when visiting more conferences and adding new ideas. The approach I’ve been taking is to use a Micro-Service architecture. So every app runs in a container and is responsible for only one job. This will ensure that every part of the system can be scaled and monitored separately.There is still a lot of work to be done but its now a working example. I will need to improve for example my dockerfiles because at the moment my images seem to be rather big for the little work they do. I also would love to include some tests and health checks. And maybe even change the code to typescript. disclaimer: This code is still a work in progress so if you want to help out or just improve my bad coding style the check out the projects on github. - TwitStreamReader: This will read a certain value from the Twitter API. This can be a hashtag or a user for example. Then it will drop everything received in an Azure Storage table and place an item in a queue for further processing. - DataExtracter: The data returned from the Twitter API is a huge JSON object. The task of this app is to read the JSON and update the row in the table with the json converted to different columns and there values. After this is done it will add an item to another queue so that the next app will know which items are processed. - PictureTranslater: This is will read items from a queue and then starts to call the Microsoft Cognitive Services API with the URL of the profile image of the user it’s processing. The values returned will then be added to the row in the table. For every part of service there is also a docker container available from the docker hub.

Azure Container Service

When researching my session on the Azure Container Service I noticed that to get to the DCOS and marathon UI is quite a hassle. You must connect to your ACS thru an SSH tunnel. This means that when doing this, your localhost url is now connected to the Azure Container Service. This is not easy if you want to use it on your local machine for lets say development or just to run containers on you dev box. If you want to know more about the Azure Container Service, how to set it up or how to play with it just follow this link to the overview. Or simple take a free trail in Azure and start playing with it.