<?xml version="1.0" encoding="utf-8"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Posts · Mesh Refinement</title><link>https://meshrefine.com/en/tags/oauth/</link><description>Posts · Mesh Refinement</description><atom:link href="https://meshrefine.com/en/tags/oauth/index.xml" rel="self" type="application/rss+xml"/><lastBuildDate>Thu, 19 Jun 2025 20:14:35 +0200</lastBuildDate><item><title>MCP's June Update: Safer, Smarter, Simpler?</title><link>https://meshrefine.com/en/posts/mcp_update_18_06_2025/</link><description>&lt;p&gt;The Model Context Protocol, despite its aggressive adoption (or perhaps because of it), continues to evolve. &lt;a href="https://modelcontextprotocol.io/specification/2025-06-18/changelog"&gt;Anthropic recently updated the MCP specification&lt;/a&gt;, and below, we&amp;rsquo;ll look at the main changes.&lt;/p&gt;
&lt;h2 id="0c0bef0c025560d849b4de6b55b2f23e-security-enhancements"&gt;Security Enhancements&lt;/h2&gt;
&lt;p&gt;An MCP server is now always classified as an &lt;code&gt;OAuth Resource Server&lt;/code&gt;, and clients are required to implement &lt;a href="https://www.rfc-editor.org/rfc/rfc8707.html"&gt;Resource Indicators (RFC 8707)&lt;/a&gt;. This is necessary to protect against attacks like the &lt;a href="https://en.wikipedia.org/wiki/Confused_deputy_problem"&gt;Confused Deputy&lt;/a&gt;. Previously, tokens requested by a client from an authorization server were &amp;ldquo;impersonal,&amp;rdquo; meaning they could be used by anyone. This allowed an attacker to create a phishing MCP server, deceive a client, steal the token, and use that token to gain access to the real MCP server.&lt;/p&gt;</description><pubDate>Thu, 19 Jun 2025 20:14:35 +0200</pubDate><guid>https://meshrefine.com/en/posts/mcp_update_18_06_2025/</guid></item></channel></rss>