3 ms·

I am very curious how many MCP servers will actually implement all of this: "MCP authorization today is built around a person approving access in a browser. Th

by izend 1mo ago

I am very curious how many MCP servers will actually implement all of this: "MCP authorization today is built around a person approving access in a browser. That works well for interactive clients, but more and more of the callers are agents running as cloud workloads with their own identity, acting on behalf of a user who isn’t present, or delegating narrower authority to sub-agents. We want MCP servers to have a standardized way to recognize and trust those agent identities, built on existing standards rather than pasted API keys and long-lived tokens. The work here covers finalizing Demonstrating Proof of Possession (DPoP) and driving its adoption, and defining an opinionated path for agent identity and delegation through Workload Identity Federation, the ID-JAG grant behind Enterprise-Managed Authorization, and standard token exchange. We will also continue to grow our engagement with the OAuth standards bodies, including the IETF OAuth and WIMSE working groups, to help the underlying standards evolve with the building blocks that agent identity needs."

aliasxneo 1mo ago
I've been working on a protocol that promises all of that and more. We're currently targeting a NOSTR/Buzz demo in the coming week as a proof of concept.
bandofthehawk 1mo ago
Even now, the mcp server itself doesn't have to implement all of the possible security options. You can use something like agentgateway to act as an auth proxy for your mcp servers.
huksley 1mo ago
Such an example of overengineering, why not just use OAuth?
- brookst 1mo ago
  Oauth assumes interactivity
  - lll-o-lll 1mo ago
    No. Client assertion flow is for services (or agents).
    - brookst 1mo ago
      Thanks, TIL. Will read up.
- dayjah 1mo ago
  WIF works far better when you don’t want humans in the loop. For example, we’d do our development on cloud instances, those have identity linked to our humans via our IdP. Our IdP governs all access, for example: it lets devs use Datadog. If an agentic workflow needs Datadog access and the MCP requests OAuth that slows the loop down. At the same time, we don’t want Service Accounts everywhere because we need to be able to answer “who” a lot for compliance reasons.
- lll-o-lll 1mo ago
  The dpop thing is oauth. It’s providing a significant enhancement to preventing token replay, or token theft, at the cost of some request size bloat + an additional key verification.
- ljm 1mo ago
  Any service offering MCP that doesn't already have OAuth set up is going to have to build out that support first, so instead they just go for a simple API token. I wouldn't call it trivial to drop in OAuth either because the authentication is one part, but wiring it up into whatever authorization set up they have is another bit of work. An AI agent would get the most benefit out of OAuth + ephemeral service accounts (the user is having a bot act on behalf of it) + fine grained scopes.
jstummbillig 1mo ago
Why, directionally all of them. What they say is obviously true. Having to manually click things in the browser is a bottleneck and will be less and less acceptable for serious users. And the individual work attached to making that transition will be done by agents.
gz5 1mo ago
agree. it seems there are two streams and they could diverge or converge? 1. workloads use existing credentials support RFC 7523 and OIDC discovery, 'trust the trust (credentials) which has already been established'. basically extend current dominant NHI paradigm. 2. DPoP mandate a signed proof for each request. so tie credential to a client-held key and specific request detail or context. viable to do at scale with #1, or does it diverge (e.g. because most #1 methods as most are not designed for DPoP?
- maxwellg 1mo ago
  It is viable. Think of workload identity federation as the mechanism for the client to get an bearer token initially, and DPoP as the mechanism for the client to present the access token to a resource server. Each DPoP proof is entirely self-contained, so resource servers don't need to manage any additional state. The only new state is the (usually ephemeral) private key held by the client: 1. Client generates a private/public keypair and uses it to generate DPoP Proofs - JWTs containing the entire public key embedded as a JWK within 2. Client presents credentials (WIF, client creds, auth code, etc.) to the Authorization Server along with a DPoP Proof 3. Authorization Server validates DPoP Proof and adds a claim to the access token containing the thumbprint - the SHA-256 hash - of the public JWK. 4. Resource Servers will now see the thumbprint claim and now know the access token needs to be presented with a fresh DPoP proof. 5. Clients generate fresh DPoP proofs and send them along with the access token There are lots of additional details around nonces, timestamps, per-request binding, etc. but DPoP can be rolled out to any HTTP system that speaks Bearer token already.
  - otabdeveloper4 1mo ago
    Are you reinventing SPIFFE here?
    - maxwellg 1mo ago
      No - this is built on top of SPIFFE/WIMSE work to enable cross-domain usage where the target domain speaks OAuth instead. You wouldn't expect, say, Slack's APIs to accept SPIFFE SVIDs from your internal deployment. This provides a path for you to exchange your SVID for a Slack-issued Access Token.
alasano 1mo ago
Hopefully quite a few. I really love the idea of fully enabled agents and being able to cut down on human in the loop moments. Things like https://projects.dev/ https://projects.dev/ for example. A ton of security problems and others to solve but it's still where I want the future of all this to go.
_puk 1mo ago
Authorization for sub-entities is what is needed. Having to define what an agent can do when it identifies on my behalf is cumbersome, especially when you start to get specialised agents. Pattern based would be too easy for AI to game, but there's got to be a service independent way to limit permissions based on role. I am Jack's right ear - awesome you get to hear stuff. I am jack's right hand - great you get to input stuff.
- kelseyfrog 1mo ago
  I am Jack's synaesthesia.
  - ethbr1 1mo ago
    What people who care about security want -- finely grained permissions that guarantee security boundaries, at the expense of bad UX What most end users want -- for the machine to do what they want, as often as possible, while bothering them as little as possible Windows' UAC journey is a microcosm of the space. The real long-term win is defining ground level permissions around common use cases, so that when composed they can alert as rarely as possible. But that's an all-of-ecosystem change: the OS (providing usable boundaries), applications (updating to use minimal boundaries), and users (understanding what they'll need to approve/deny).
    - mooreds 1mo ago
      Yeah. If we want fine grained "intelligent" authorization, there's a lot of work to be done. You can't simply slap a gateway on existing systems. I wrote about this more on my employer's blog[0]. > The real long-term win is defining ground level permissions around common use cases, so that when composed they can alert as rarely as possible. And this is an even larger effort to implement, especially as agent capabilities change over time (and they are changing rapidly). 0: https://fusionauth.io/blog/ai-authorization https://fusionauth.io/blog/ai-authorization
- niyikiza 1mo ago
  This. Especially when you have agents calling other agents. Just published an article about that yesterday: https://niyikiza.com/posts/agents-to-agents/ https://niyikiza.com/posts/agents-to-agents/
zackify 1mo ago
I think the spec overcomplicates everything honestly. Its not that hard to add a long running auth token and put it in the MCP config as a header to send along and then avoid all the extra special rules. "Oh no it's a long lived token that's bad" Put it in a secret manager like 1pw cli and now start an agent...
- danappelxx 1mo ago
  How does the agent auth with 1pw? How do you give it access to only the credentials it needs, with an approval flow and revocation? Who renews the token? You’ll likely end up reinventing something pretty close to what MCP is building towards. Authn/authz is one of those things that can be really simple for pointed use cases but gets really complex when you need to support everything.
  - blazarquasar 1mo ago
    Quite a few options as of now: https://www.1password.dev/get-started/secure-ai-access#secure-mcp-server-config-files https://www.1password.dev/get-started/secure-ai-access#secur... https://1password.com/blog/1password-trusted-access-layer-for-openai-codex https://1password.com/blog/1password-trusted-access-layer-fo... Still far from perfect tho.
  - elenaviter 1mo ago
    There might be the "agent card" - one place where the user manages what a specific agent is allowed to do. The user grants it tools, connects the accounts those tools need, narrows or revokes any of that at any time. For an autonomous agent the card is prepared and consented before the run. Such card is the primitive in so called "connection hub", a centralized component, and is rendered from what is declared there: tools declare their claims, accounts get connected in the browser (google docs tools need a google account connected), on their own or as part of preparing the card. Account credentials live in this hub, with the claims the user approved when connecting. The agent authenticates with one token issued for this card and never receives the connected accounts credentials. Every operation is checked against the grant and this agent's binding to the account. If something is missing, the agent gets unauthorized with the details on what exactly. If the check passes, the hub, loaded by the server as a lib or reached in its internal network, releases the account credential into the operation's execution context. Account credentials renewal happens on hub. Revoking grant is also done in card and leads to agent's unauthorized on that op next call. Sub-agent and any automation are also such agents and also can be managed with such card. So such hub develops into a useful ecosystem component, standalone, like an IdP for login. An MCP server then works together with this hub, it only declares its claims in the hub (so the hub knows what to render in the agent card). While all these auth realm duties such as approvals, the revocation and the credentials storage live "at infrastructure".
shan-chang 1mo ago
[flagged]

by izend 1mo ago

aliasxneo 1mo ago

I've been working on a protocol that promises all of that and more. We're currently targeting a NOSTR/Buzz demo in the coming week as a proof of concept.

bandofthehawk 1mo ago

Even now, the mcp server itself doesn't have to implement all of the possible security options. You can use something like agentgateway to act as an auth proxy for your mcp servers.

huksley 1mo ago

Such an example of overengineering, why not just use OAuth?

brookst 1mo ago
Oauth assumes interactivity
- lll-o-lll 1mo ago
  No. Client assertion flow is for services (or agents).
  - brookst 1mo ago
    Thanks, TIL. Will read up.
dayjah 1mo ago
WIF works far better when you don’t want humans in the loop. For example, we’d do our development on cloud instances, those have identity linked to our humans via our IdP. Our IdP governs all access, for example: it lets devs use Datadog. If an agentic workflow needs Datadog access and the MCP requests OAuth that slows the loop down. At the same time, we don’t want Service Accounts everywhere because we need to be able to answer “who” a lot for compliance reasons.
lll-o-lll 1mo ago
The dpop thing is oauth. It’s providing a significant enhancement to preventing token replay, or token theft, at the cost of some request size bloat + an additional key verification.
ljm 1mo ago
Any service offering MCP that doesn't already have OAuth set up is going to have to build out that support first, so instead they just go for a simple API token. I wouldn't call it trivial to drop in OAuth either because the authentication is one part, but wiring it up into whatever authorization set up they have is another bit of work. An AI agent would get the most benefit out of OAuth + ephemeral service accounts (the user is having a bot act on behalf of it) + fine grained scopes.

jstummbillig 1mo ago

Why, directionally all of them. What they say is obviously true. Having to manually click things in the browser is a bottleneck and will be less and less acceptable for serious users. And the individual work attached to making that transition will be done by agents.

gz5 1mo ago

agree. it seems there are two streams and they could diverge or converge? 1. workloads use existing credentials support RFC 7523 and OIDC discovery, 'trust the trust (credentials) which has already been established'. basically extend current dominant NHI paradigm. 2. DPoP mandate a signed proof for each request. so tie credential to a client-held key and specific request detail or context. viable to do at scale with #1, or does it diverge (e.g. because most #1 methods as most are not designed for DPoP?

maxwellg 1mo ago
It is viable. Think of workload identity federation as the mechanism for the client to get an bearer token initially, and DPoP as the mechanism for the client to present the access token to a resource server. Each DPoP proof is entirely self-contained, so resource servers don't need to manage any additional state. The only new state is the (usually ephemeral) private key held by the client: 1. Client generates a private/public keypair and uses it to generate DPoP Proofs - JWTs containing the entire public key embedded as a JWK within 2. Client presents credentials (WIF, client creds, auth code, etc.) to the Authorization Server along with a DPoP Proof 3. Authorization Server validates DPoP Proof and adds a claim to the access token containing the thumbprint - the SHA-256 hash - of the public JWK. 4. Resource Servers will now see the thumbprint claim and now know the access token needs to be presented with a fresh DPoP proof. 5. Clients generate fresh DPoP proofs and send them along with the access token There are lots of additional details around nonces, timestamps, per-request binding, etc. but DPoP can be rolled out to any HTTP system that speaks Bearer token already.
- otabdeveloper4 1mo ago
  Are you reinventing SPIFFE here?
  - maxwellg 1mo ago
    No - this is built on top of SPIFFE/WIMSE work to enable cross-domain usage where the target domain speaks OAuth instead. You wouldn't expect, say, Slack's APIs to accept SPIFFE SVIDs from your internal deployment. This provides a path for you to exchange your SVID for a Slack-issued Access Token.

alasano 1mo ago

Hopefully quite a few. I really love the idea of fully enabled agents and being able to cut down on human in the loop moments. Things like https://projects.dev/ https://projects.dev/ for example. A ton of security problems and others to solve but it's still where I want the future of all this to go.

_puk 1mo ago

Authorization for sub-entities is what is needed. Having to define what an agent can do when it identifies on my behalf is cumbersome, especially when you start to get specialised agents. Pattern based would be too easy for AI to game, but there's got to be a service independent way to limit permissions based on role. I am Jack's right ear - awesome you get to hear stuff. I am jack's right hand - great you get to input stuff.

kelseyfrog 1mo ago
I am Jack's synaesthesia.
- ethbr1 1mo ago
  What people who care about security want -- finely grained permissions that guarantee security boundaries, at the expense of bad UX What most end users want -- for the machine to do what they want, as often as possible, while bothering them as little as possible Windows' UAC journey is a microcosm of the space. The real long-term win is defining ground level permissions around common use cases, so that when composed they can alert as rarely as possible. But that's an all-of-ecosystem change: the OS (providing usable boundaries), applications (updating to use minimal boundaries), and users (understanding what they'll need to approve/deny).
  - mooreds 1mo ago
    Yeah. If we want fine grained "intelligent" authorization, there's a lot of work to be done. You can't simply slap a gateway on existing systems. I wrote about this more on my employer's blog[0]. > The real long-term win is defining ground level permissions around common use cases, so that when composed they can alert as rarely as possible. And this is an even larger effort to implement, especially as agent capabilities change over time (and they are changing rapidly). 0: https://fusionauth.io/blog/ai-authorization https://fusionauth.io/blog/ai-authorization
niyikiza 1mo ago
This. Especially when you have agents calling other agents. Just published an article about that yesterday: https://niyikiza.com/posts/agents-to-agents/ https://niyikiza.com/posts/agents-to-agents/

zackify 1mo ago

I think the spec overcomplicates everything honestly. Its not that hard to add a long running auth token and put it in the MCP config as a header to send along and then avoid all the extra special rules. "Oh no it's a long lived token that's bad" Put it in a secret manager like 1pw cli and now start an agent...

danappelxx 1mo ago
How does the agent auth with 1pw? How do you give it access to only the credentials it needs, with an approval flow and revocation? Who renews the token? You’ll likely end up reinventing something pretty close to what MCP is building towards. Authn/authz is one of those things that can be really simple for pointed use cases but gets really complex when you need to support everything.
- blazarquasar 1mo ago
  Quite a few options as of now: https://www.1password.dev/get-started/secure-ai-access#secure-mcp-server-config-files https://www.1password.dev/get-started/secure-ai-access#secur... https://1password.com/blog/1password-trusted-access-layer-for-openai-codex https://1password.com/blog/1password-trusted-access-layer-fo... Still far from perfect tho.
- elenaviter 1mo ago
  There might be the "agent card" - one place where the user manages what a specific agent is allowed to do. The user grants it tools, connects the accounts those tools need, narrows or revokes any of that at any time. For an autonomous agent the card is prepared and consented before the run. Such card is the primitive in so called "connection hub", a centralized component, and is rendered from what is declared there: tools declare their claims, accounts get connected in the browser (google docs tools need a google account connected), on their own or as part of preparing the card. Account credentials live in this hub, with the claims the user approved when connecting. The agent authenticates with one token issued for this card and never receives the connected accounts credentials. Every operation is checked against the grant and this agent's binding to the account. If something is missing, the agent gets unauthorized with the details on what exactly. If the check passes, the hub, loaded by the server as a lib or reached in its internal network, releases the account credential into the operation's execution context. Account credentials renewal happens on hub. Revoking grant is also done in card and leads to agent's unauthorized on that op next call. Sub-agent and any automation are also such agents and also can be managed with such card. So such hub develops into a useful ecosystem component, standalone, like an IdP for login. An MCP server then works together with this hub, it only declares its claims in the hub (so the hub knows what to render in the agent card). While all these auth realm duties such as approvals, the revocation and the credentials storage live "at infrastructure".

shan-chang 1mo ago

[flagged]