Agentic Workflow Authorization
How can agents participating in a workflow get authorization to access APIs?
Most public APIs aren't available to anonymous users. Even private APIs only available inside a protected environment often require authentication. It's normal and expected that you need credentials to access an API. We all agree that this is the reality for integrations built by people. So, what happens when an AI agent tries to access a protected API for the first time? Follow me to explore the possibilities.
This article is brought to you with the help of our supporter, n8n.
n8n is the fastest way to plug AI into your own data. Build autonomous, multi-step agents, using any model, including self-hosted. Use over 400 integrations to build powerful AI-native workflows.
When consumers want to integrate with an API, they usually need valid credentials. Without authentication, their requests won't get anywhere. Authentication is, therefore, a requirement for integrating with an API. To get their credentials, human consumers go to the API documentation and find instructions. Getting API credentials usually involves signing up to use the service and then copying a client ID and secret into the code that makes the requests. Sometimes it's even simpler than that if you only need to use API keys. In any case, this process is well understood and easy to replicate. What happens when, instead of a human, you have an AI agent making its first request to an API?
How would an AI agent find out what it has to do to obtain the API credentials? How would an AI agent sign up to use the API? How would it copy the API key or a client ID and secret? Where is the code responsible for the integration with the API? So many questions. I'm sure you can find different answers depending on the solution you follow. That's why I prefer to focus on one that I find promising: the Model Context Protocol (MCP). I wrote about it here before and explained why it makes it easier for agents to connect to any API. The missing piece of that article was, as obvious as it feels now, authorization. Luckily for everyone, things have changed since then.
One of the major changes of MCP that was announced on March 26, 2023, is related to authorization. According to their changelog, they "added a comprehensive authorization framework based on OAuth 2.1." Before this change, there was no guidance on how tool implementors should provide authorization. What ended up happening was different tool vendors implementing what they thought was the best authorization scheme. Despite all this, behind the scenes, there was a group of people dedicated to standardizing authorization support. Their work began on January 29, 2025, with PR #133 and evolved into PR #284, which contained the actual changes to the spec. So, what are we actually talking about?
First of all, authorization is optional, which makes sense. However, when supported, it should follow a few guidelines if the MCP server works over the HTTP transport. Otherwise, it should follow the best practices for the transport layer it uses. For HTTP MCP servers, the flow is based on OAuth 2.1. Furthermore, it should support the OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591), which I covered in April 2024. Last but not least, it should also support OAuth 2.0 Authorization Server Metadata (RFC 8414) or, alternatively, follow the default URI schema. In summary, MCP clients should be able to automatically find all the URIs they need to do a machine-to-machine signup, followed by an authorization flow to obtain an OAuth token that the MCP server can use on every subsequent request to the third-party API. The authorization flow—also known as grant type—depends on the use case. If the agent is acting on behalf of a user, then the most appropriate grant type is the "authorization code." On the other hand, if the agent isn't impersonating a real user, then the "client credentials" grant type is good enough.
If all this sounds complicated, that's because a lot is going on behind the scenes. I'll try to simplify it with the following diagram. Hopefully, we'll all understand how MCP authorization works. Let's see.
At this point, it should be easier to understand what the authorization options are. It all begins with the transport you're using. If it's not HTTP, then nothing else in this article applies to you. Then, if the authorization server doesn't provide metadata, you'll have to use the default OAuth URIs. Finally, the last question to answer is whether the MCP client is acting on behalf of a user. If not, then using an OAuth client credentials grant type is more than enough. Otherwise, you need to use an authorization code grant type. Hopefully, you'll be able to abstract all these decisions behind the code of your MCP implementation.