The Essence of OAuth 2.0: MCP Edition

Defining the problem

You’re a finance operator who saw that Sequence just launched an MCP server. You’re eager to add it as a connector in Claude so it can help with your day-to-day. However, what are you adding the connector to do? You want Claude to take actions on your behalf - not irreversible operations such as sending an invoice, but creating customers could be helpful.

You need to grant it a subset of your permissions in a way that the system can distinguish Claude’s actions from your actions and so you can revoke them in future. To do that, we need to dive into OAuth 2.0.

Once upon a time: sharing credentials and its pitfalls

The old “solution” to this problem was to simply give your exact credentials to Claude. Then Claude could reuse those credentials to take actions on your behalf by going straight to an API and presenting those credentials.

However, as an astute reader may notice, there are several glaring holes in this primitive approach:

• Scoping permissions: Claude will have the exact same set of permissions as you. If you have full admin privileges, then Claude will too. There is no way to restrict Claude’s permissions to only a safe subset
• Revoking access: There is no way for you to revoke Claude’s access to take actions on your behalf, short of revoking your own credentials
• Auditability: Since Claude is impersonating you, there is no way for the API to distinguish between Claude and yourself when a request comes in

We need a much better solution. Enter OAuth.

This isn't a new problem. In the mid-to-late 2000s, before there was a standard way to delegate API access, users routinely handed their username and password to third-party apps so those apps could post to their Facebook account or pull photos from their Flickr library.

OAuth was created to solve this: it lets you grant a third party scoped, revocable access to act on your behalf without ever sharing your password.

The actors of OAuth

Using OAuth, you can give a third party access to a subset of your permissions to a service. In our case, that means you can give Claude access to specific actions within your Sequence account. This is also known as delegated authorization.

In the OAuth framework, we can formally define our main participants of the authorization and delegation flow:

• Resource server: this is the server which serves the protected resource. In our case, the Sequence MCP server. It requires authentication/authorization to access
• Resource owner: the owner who has access to the resource server, e.g. a user within a Sequence workspace
• Client: the participant acting on behalf of the owner of the resource. For us, this is Claude.ai wanting to access the Sequence MCP server on behalf of the user
• Authorization server: here’s the new piece which bridges the gap between the client and protected resource. This server’s purpose is to issue special access tokens to clients, scoped by the permissions the resource owner granted

Let’s now walk through how these components play together in practice to solve our delegation problem. We’ll break things down step by step to build a strong mental model of the flow, using our MCP as an example. Let’s call our finance operator friend John, for simplicity.

The goal is to grasp the essence of OAuth, without being too bogged down in details. Let’s begin!

OAuth: a dialogue

Step 1: Discovery

John: I’ll add the Sequence MCP as a connector, so Claude can read invoices on my behalf. I’ll just paste the URL of the MCP server into Claude (https://eu.sequencehq.com/mcp), and click “Connect”.

Claude: Hey, here’s a new MCP server! I’ll send a GET request to this endpoint to discover the MCP.

Sequence backend: Sorry, but there’s no credentials in this request. I do not know who you are. I’ll send back a 401 Unauthorized. However, I’ll also tell you how you can authenticate yourself by using the WWW-Authenticate header, as specified in RFC 7235. You may use a bearer token, and to find out how to get one, go to https://eu.sequencehq.com/.well-known/oauth-protected-resource.

Claude: Okay, I’ll send a GET request to https://eu.sequencehq.com/.well-known/oauth-protected-resource and see what it says.

Sequence backend: Here’s a JSON document describing how to get a token:

Claude: I see, so to authenticate myself I must go to the authorization server located on Stytch (https://api.stytch.sequencehq.com). This server will grant me the tokens I need to access the Sequence MCP server resource.

Step 1 complete! Here’s a flow diagram of this exchange:

Step 2: The Authorization Server

Claude: Hey, Stytch, please show me all of your metadata so I know exactly how I can register myself with you and kick off the flow for getting an access token. I’ll do this by sending a GET to https://api.stytch.sequencehq.com/.well-known/oauth-authorization-server

Stytch: Here’s everything I support in the form of a JSON metadata document:

Claude: Okay, I’ll now register myself as a new client to you, so you can keep track of who I am in the future, by hitting https://api.stytch.sequencehq.com/v1/oauth2/register. This flow is called Dynamic Client Registration (DCR), as defined in RFC 7591. Also, please redirect John back to https://claude.ai/... after he logs in on your side.

Stytch: I have registered you, here’s your client id: connected-app-test-3139a9b7-6444-4d95-b29a-8309ddef8d8d

Step 2 complete! Here’s a flow diagram of this exchange:

Step 3: Delegation

Claude: Got it. Now I need John to actually give me permission to act on his behalf. I’ll open the browser to https://dashboard.sequencehq.com/oauth/authorize which runs the Stytch SDK and shows a consent prompt asking “Do you want to grant Claude the following permissions?”.

Stytch: I see that John has some valid session cookies in his browser which is how I can identify him as John. If he were logged out, I would ask him to log in to Sequence so I know that this is really John.

John: Aha! The consent prompt appeared, as expected. These permissions look fine to me, so I’ll simply click “Accept”.

Stytch: I see that John agreed to grant the permissions. I’m now going to redirect John back to Claude.ai, with a one-time code Claude can use to obtain tokens to authorize itself. I know where to redirect John because Claude gave me the redirect URI earlier.

Claude: I see John is back and has a one-time code. I’ll now use this code to get a bearer token from Stytch directly.

Stytch: The code is valid so I now know that the authorization flow was successful. I will now give you a bearer token, which represents the permission John gave you to access the Sequence MCP. The bearer token is short-lived, so I’ll also give you a refresh token which you can use to fetch a new bearer token.

Step 3 complete! Here’s a flow diagram of this exchange:

Finally: Back to the resource server

Claude: Thanks! Finally, I’m ready to talk to the Sequence MCP server. I’ll send a GET <https://eu.sequencehq.com/mcp> request and include the bearer token.

Sequence backend: Let me authorize you… I see, this is Claude acting on behalf of John, with a specific set of permissions. Success, you can now talk to me (the MCP) and do your thing.

Claude: List tools please.

Sequence backend: Send invoice, list customers.

Claude: Send invoice INV00001.

Sequence backend: No, John did not give you permission to do that.

Claude: Fine, list customers.

Sequence backend: Google, Microsoft, Amazon.

Note: this is for illustration purposes. The Sequence backend doesn’t currently expose a send invoice tool :)

Bringing it all together

Zooming out, here’s our overall flow:

Conclusion

OAuth is a complex and interesting protocol with many details, but I hope that by now you’ve understood the essence of the problem it’s trying to solve, how it solves that problem and how we use it to guarantee secure delegation in the context of our own MCP server.

Want to tackle technical challenges such as spinning up an MCP server with OAuth end-to-end? We’re actively hiring! Check our available roles at https://jobs.ashbyhq.com/sequence.