Hey, everyone. I'm Pranami. I'm an engineer at Microsoft, working at the intersection of AI security and cloud infrastructure.I'm very excited to be here at the sixth annual Women in Tech Conference. A little bit about me. Over the past few years, I have focused on building secure authentication and authorization workflows, not just for traditional apps, but for also for intelligent agents and AI powered systems, which we all are hearing about a lot these days. I also run a blog called the oauthgrill.com, where I break down OAuth API security and practical implementation tips for developers. In this session, we are going to explore how OAuth has evolved into a modern framework for secure access. We'll talk about its core flow, how it evolved, and how it applies to everything from APIs, web apps, to AI tools.

We're also gonna talk about the best practices, key takeaways, and the strengths in the flow pitfalls for the OAuth. Towards the end, I'll walk you through a real world scenario, an example using something called model context protocol, MCP, a new way for AI agents to securely access APIs using OAuth. Let's kick things off with a quick distinction between authentication and authorization. Authentication what is authentication? It's literally who are you. Are you really who you say you are? And authorization, on the other hand, it's about control. Once you are in, what are you actually allowed to do? Think about logging into Spotify with your Google account. That's authentication. And when Spotify requests permission to view your name, your profile, and your email, but it does not ask to view for your calendar, That's authorization, meaning what you are allowed to access.

OAuth was designed to handle the second part beautifully, securely, and with precision. How it binds together the identity and access. It bridges identity and access very beautifully. You first authenticate maybe through OpenID Connect. You all must have seen login via Google, login via Microsoft, etcetera. That's OpenID Connect. And OAuth then issues a token that defines exactly what the client can do. It's not just a yes or no access. It's access with conditions. Let's say you connect a photo editing app to your Dropbox. OAuth ensures it can only read images in a specific folder, not your entire account. That's cool. And something goes wrong, access is revocable. It's immediate. You can just revoke the access. Think of it, authentication is the door lock, and authorization is what rooms you're allowed to go into. Why it matters today so much.

So nearly every action we take online, it whether it's from messaging a friend to submitting a reimbursement form, everything goes and hits an API. And behind those APIs, there is a sensitive data, all of it needing protection. Personal data, financial records, company secrets, all needing protection. Over eight percent of data breaches involve weak or stolen credentials. Apps today are decentralized using third party APIs, microservices, and mobile clients. So we need a safe way to grant limited access without handing over passwords. That's where OAuth comes in. OAuth gives us the ability to control API access without sharing credentials, without giving your password to someone. We issue scoped tokens, limit their spam, lifespan, and revoke them when needed. It's flexible, it's scalable, and it fits today's API first data rich world.

Let's talk about the evolution of OAuth. It wasn't born perfect. It's evolved. OAuth one point o, that's the first thing that came in. It was secure, but very complicated, very clunky, hard to get. Then comes two point o. It was simple, broad broadly adopted. It was it brought in flexibility, quickly became the industry standard. And now, today, we have OAuth 2.1, a leaner, more secure version that simplifies decisions for developers. You must have heard about a lot of grant flows, like authorization code grant, client credentials, implicit device flow, and whatnot. But Pixie, that's becoming the standard as of now, it's required by default. Implicit flow, it's gone, and best practices are baked right in. The core idea. What exactly in oh, like, it's it's what is a what? In Lemon Towns, it's about delegated trust.

Instead of giving your actual password to an app, you give it a temporary limited access token. You've seen this in action, logging into fitness app with Apple or Google. What ensures the app can only access what you allow? Maybe your step count, but not your email or contacts. It's access with boundaries and ability to audit and revoke at any time. How do you choose the right flow? As I've just mentioned, there are multiple flows for OAuth, but how do you choose the one that's right for you? So it's it's OAuth is what separates responsibilities into four roles. There is a resource owner, client, authorization server, and a resource server. User own user owns the data here. That's the resource owner. Clients like a mobile app wants access. Authorization server that issues the token.

Think about it as as like Google that issues the token or Microsoft that issues the token or Entra Entra from Microsoft that issues the token. And resource server, that's usually an API grants access based on that token. Maybe Dropbox, that's a resource you want access to. Or your fitness app that wants like, it could be Apple Health that wants access to your data. That's what the resource is. With OAuth, it's clean, modular design that keeps access secure and transparent. How do you know what flow is right for you? There is authorization code plus PIXI, which is with OA 2.1 that's involved. It's for web and mobile when there are multiple options, for choosing the right flow. And if it's web and mobile, I would blindly go and choose authorization code plus Pexy. From machine to machine scenarios, use client credentials.

Smart TVs or IoT devices, you have seen that. When you want to connect to an app, it says enter this code, go to this link, and enter this code to connect to your TV. That's device code. And implicit flow, that's retired. Let's not talk about it. It's deprecated. If you still see it in legacy apps, it's time for a rewrite. Best practices. So here's the checklist that I live by when securing OAuth implementations. Always use short lived tokens and refresh tokens to extend sessions securely. For your API service, if you're implementing an OAuth, never ever implement a policy that issues the access token for more than an hour. That's standard. PIXIE is a must, especially for mobile and SPS. What is PIXIE?

It's it's the OAuth flow, but it does not even need a client secret or client certificate or anything. It's credulous. But if you're using, say, client credentials or auth code grant, always rotate your client secrets. Enforce scopes with intention. Don't give full access when read only is what you only do need to give. Please don't store tokens in local storage. That's a no no. Use secure HTTP only cookies or encrypted stores. We've talked a lot about what is OAuth, how it evolved, how it's going, what flow to use. Let's talk about real world use case. Today, everyone is talking about AI agents. So let's switch gears and talk a little bit about AI. You must have heard about Claude. It's an AI agent. Imagine Claude, an AI agent, writing pull requests, fetching files, or querying financial systems. That's powerful, but potentially risky.

OAuth allows us to scope Cloud's access. Want it to read dashboards but not delete them? Done. Every action is tied to a token. Every token is time limited, traceable, and rebokable. You get the full flexibility of agents, but without the fear of overreach. So now the question is, how do AI agent like Claude express these requests in a consistent, structured, and secure way? We have lots of agents, but we wanna make sure all of these agents follow a pattern or, like, a structured and secure way to access your servers. That's where something called model context protocol, or we call it MCP, comes in. What is MCP? It enables seamless integration between LLM apps and external data sources. It's a framework that's making secured structured AI to tool communication actually possible. It was developed by Anthropic, and it's quickly leaning traction.

You must have seen everyone on LinkedIn or X are talking about NCP. Everything is revolving around MCP because today is the world where we are living in the era of agents, AI. Instead of unpredictable prompts or ad hoc API calls, MCP lets AI agents and structure intents, like create a GitHub repo or fetch the latest invoice. These intents are consistent, interpretable, and machine friendly. That's why it's being adopted across teams at Anthropic. We at Microsoft are working on designing this protocol as well. It's it's open source, so that's the best thing about it. Any developer can go and have their voice to and make sure how this shapes the future. But a well informed intent is good. But is it really secure? I don't think so. We still need to validate and secure what happens next.

That's where OAuth comes in. It ensures every intent is authorized. It checks who is sending it, what scope have been granted, and whether it's permitted. It's like an agent showing up with a signed access badge, valid only for certain tasks and only for a set period of time. So I would say MCP gives AI a structured voice in what it ensures that voice is trusted. Let's talk about how we are enhancing security for MCP server. We're gonna see all of it together in practice, and I will be showing you a working demo of this in just a moment. Before I dive into that, I wanna talk a little bit about what I'm gonna be showing you in the demo. So this architecture that you're seeing on screen, it involves three components here. One is MCP client, and one second is MCP servers. And you see something in between.

That's Azure API management. We at Microsoft, we are proposing Azure API management as an AI odd gateway to handle all your OAuth related, needs. Implementing OAuth can be challenging, and that's where all the heavy heavy lifting comes in. And you can do all of that in Azure API management. So and we are using you're you're also seeing something called Microsoft Entra ID. So for this demo purpose, I'll be using Entra ID as my authorization server. Remember, I talked about the four components of OAuth. One is the user. So user is gonna be interacting with other clients. Resource server, which is our MCP servers here. There is an auth server, which is Microsoft Entra ID here. That's being enforced within Azure API management. So for the demo, in terms of clients, we have multiple clients available right now. There is Cloud. There is Visual Studio Code. There is GitHub Copilot.

There is chat GPT. There is bunch more. For demo purposes, I'll be using Cloud and something called MCP Inspector that lets you test all of these, things. An author request for the user will begin with NCP client calling the Azure API management, our AI auth gateway. Gateway will then redirect the call to your remote NCP server. Remote MCP server, I just use this term. It's it's nothing but, your API, your data, and everything, that's available on the cloud. And we'll be using Microsoft Entra for login and consent. That's authentication. And once the user will be authenticated, they'll be able to talk to MCP servers and perform actions. So before talking much, let's see it in action. So let's start. Few things. My MCP server, I'm hosting it in Azure functions. It's a very basic MCP server that I'll be using for this demo.

It just has three endpoints called get snippet, save snippet, and just say hello MCP. How can we go without saying hello world? So just three things. Let's start. I have prerecorded this demo, so I'm gonna be walking you through the steps. I'm using, AZD thing here, and it's a partial window. AZD up is nothing but an Azure CLI command that I'm using here, that lets you spin up the resources very quickly so you won't have to write a line of code by yourself. Let's see it in action. So I've also linked the links to the repo. And, the this sample is up, by the way, in our repo. And, you guys can just go ahead and have it on your machine and see it in action by yourself. So I just ran the command easy up. It's asking me for a few things, like environment name. Like, it could be anything and subscription to you. So you need to have an Azure subscription for it.

And then it's asking me in which location I wanna deploy my services. So I'm deploying I just selected East West too. So it's just gonna deploy everything for me once so let's see. It deployed the API management instance. It deployed the function app for me where I'm hosting my remote MCP server and whatnot, like all the things that's required, APIs, policies that I'll be using here. And finally, it gives me an endpoint that I can provide to my MCP client to use to talk to my remote MCP server. And I've mentioned I will be using inspector, NCP inspector. And to run that, all you have to do is just run this one command. And I'm using open nine point o, which is the most stable version right now. So it just spins it up on local host port.

I'm just gonna copy this endpoint from here and put it in the local host window in my browser. You can see here I'm using transport type as SSE. So there is two transport types that's available, stdio and SSE. SDDIO is what lets you talk to your local MCP server. SSE here lets you talk to the remote MCP server. This inspector, I'm just showcasing for you to know what are the endpoints that I have implemented and the things that are available as tools. Once connected, you are gonna see the list of tools here. And that's it. Get snippet, hello MCP, and save snippet. Let's talk about real world. This is all testing. So I'm using Plod here, as an AI agent and as my MCP client. Claude recently announced something called custom integrations, and that's what I will be using.

So you go here. You click on settings. You have to go and click on integrations. What is integrations? It just lets you connect to multiple remote MCP servers. There is something called built in integrations, which you'll see here, Google Drive, Google Calendar, Gmail, GitHub. These are the remote MCP servers which are publicly available and you can go ahead and use it. There's something called custom integrations where I'll be putting my APIM link. I'm just going to put it here as integration URL, the same URL that we copy. Let's put the name as NCP API auth gateway demo. And once we add that, gonna see it in the chat in a minute. So it's added. Go to the chat. Start a new chat. You see these three dots here. Once you click on that, we will be seeing our custom integration added. And you see something called connect here.

So let's connect to it. It should pop up an authentication screen. As I've mentioned, I'm using Microsoft Intra. So you see the screen. It's asking for permissions saying that this app would like to sign you in and read your profile. That scopes. That's authorization. This app is not allowed to do anything except sign you in and read your profile. So let's accept it. Once accepted, it's gonna redirect me back to my cloud agent, and it should show me something called successfully connected. Awesome. So now we're gonna click on this, and you can see there are three tools available. The same one, Get Snippet, HelloMCP, and Save Snippet. Let's try one of them. Let's let's say, can you help me save a snippet? And it's gonna ask me for, you know, like, giving the name and some content.

Once we give it that, we should be able to see it being saved. That's great. Now let's just retrieve it. So I'm just gonna ask, can you also help me retrieve the snippet which we just saved? And it's gonna do it. So I'm just giving the name, and let's see if we get it. There we go. That's what we saved, and it called this tool, and that worked flawless. So, yeah, you can try out that in action by yourself. I will link all the resources in the end. The remote, the remote, GitHub repo, and there is an odd blog and every all the resources. I'll link everything. Let's talk about strengths and cautions. Obviously, it gives you OAuth gives you a solid foundation. It's flexible, widely adopted, works across users, services, agents, whatnot, but it's not invincible. Be careful with scopes.

Don't go too broad. Rotate secrets, monitor token usage, and make sure you are storing tokens in secure and encrypted formats. Or what? If done right, it's beautiful. But done wrong, it's dangerous. Key takeaways. It brings together authentication and authorization in one clean, flexible system. It scales from mobile apps to back end APIs, to AI agents, and it does all of it very securely. When implemented well, it doesn't get in your way. It protects your users, secure your system, and lets you build faster, not slower. I skipped one thing because you're running short of time a little bit here. There is something that, I wanted to show you, like, how it looks, inside APIM. I wanted to go over this flow, but I'll link the resources. You can go over it how MCP works. I was talking about API m. Here is the API m.

And when I ran that command AZD up, it spinned up this instance for me and created two APIs here. One is MCP API that lets you talk to your client with these two endpoints, and there's an OAuth API which implements all the heavy lifting of doing the authentication authorization for you. Feel free to go ahead and check this out. I have everything linked in the end. These are all the policies that gets created. It's like a lot of work there, but we don't want you to do that. Who wants stress when you're gonna have fun and have security at the same time? On the final not note, I'll leave you guys with one quote. Security should empower, not slow your development. And, yeah, thank you. Thank you so much for joining me. If you wanna go deeper, check out my blog at theoadgirl.com or visit GitHub repo for full MCP plus demo.

And, there are a few tech blogs that I've written at Microsoft. They give you, like, the whole end to end integration experience that I've just explained. I also have this blog called building cloud ready and Friday protected. It's the exact demo that we just saw. So, yeah, let's connect. I would love to hear how you're using OAuth or building secure AI system in the world. Thank you, everyone.