2026 ਵਿੱਚ MCP Authentication

Model Context Protocol (MCP) ਨੇ ਏਜੰਟਾਂ ਦੇ ਸਰਵਰਾਂ ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ ਦੇ ਤਰੀਕੇ ਨੂੰ ਬਦਲ ਦਿੱਤਾ ਹੈ। ਇਸ ਦੀ ਸ਼ੁਰੂਆਤ ਕੈਲਕੁਲੇਟਰ ਵਰਗੇ ਸਥਾਨਕ (local) ਟੂਲਸ ਨਾਲ ਹੋਈ ਸੀ। ਹੁਣ ਇਹ ਰਿਮੋਟ ਸਰਵਰਾਂ 'ਤੇ ਚੱਲਦਾ ਹੈ। ਇਸ ਬਦਲਾਅ ਨੇ authentication ਨੂੰ ਇੱਕ ਲੋੜ ਬਣਾ ਦਿੱਤਾ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ ਆਪਣੇ MCP ਸਰਵਰ ਵਿੱਚ OAuth ਜੋੜਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਲਗਾਤਾਰ ਬਦਲਦੇ ਨਿਯਮਾਂ ਲਈ ਤਿਆਰ ਰਹੋ। ਇਸਦਾ spec ਹਰ ਕੁਝ ਮਹੀਨਿਆਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ। ਵੱਖ-ਵੱਖ ਏਜੰਟ ਨਿਯਮਾਂ ਦੇ ਵੱਖ-ਵੱਖ ਵਰਜ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।

MCP authentication ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਇੱਥੇ ਦਿੱਤੀ ਗਈ ਹੈ।

ਮੁੱਖ ਬਦਲਾਅ (The Core Shift)

ਤੁਹਾਡਾ MCP ਸਰਵਰ ਇੱਕ authorization server ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ resource server ਹੈ।

ਪਹਿਲਾਂ, spec ਸਰਵਰਾਂ ਨੂੰ tokens ਅਤੇ logins ਸੰਭਾਲਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਸੀ। ਇਸ ਨਾਲ ਸਰਵਰ ਭਾਰੀ ਹੋ ਗਏ ਅਤੇ ਉਹਨਾਂ ਨੂੰ scale ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੋ ਗਿਆ। Aaron Parecki ਅਤੇ Christian Posta ਵਰਗੇ ਮਾਹਰਾਂ ਨੇ ਇਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕੀਤਾ ਸੀ। ਉਹਨਾਂ ਦਾ ਤਰਕ ਸੀ ਕਿ MCP ਸਰਵਰਾਂ ਨੂੰ ਸਿਰਫ਼ tokens ਨੂੰ validate ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਅੱਜ, standard ਇਸ flow ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ:

• ਇੱਕ unauthenticated request ਨੂੰ 401 error ਮਿਲਦਾ ਹੈ। • Error ਕਲਾਇੰਟ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ resource metadata ਕਿੱਥੇ ਲੱਭਣਾ ਹੈ। • ਕਲਾਇੰਟ ਸਹੀ authorization server (ਜਿਵੇਂ ਕਿ Okta ਜਾਂ Keycloak) ਲੱਭਦਾ ਹੈ। • ਕਲਾਇੰਟ ਇੱਕ token ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਤੁਹਾਡੇ MCP ਸਰਵਰ ਨੂੰ ਪੇਸ਼ ਕਰਦਾ ਹੈ। • ਤੁਹਾਡਾ ਸਰਵਰ token ਨੂੰ validate ਕਰਦਾ ਹੈ ਅਤੇ tool ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ।

ਫਰੈਗਮੈਂਟੇਸ਼ਨ ਦੀ ਸਮੱਸਿਆ (The Fragmentation Problem)

ਭਾਵੇਂ ਇੱਕ standard ਮੌਜੂਦ ਹੈ, ਪਰ ਹਰ ਏਜੰਟ ਇਸ ਨੂੰ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕਰਦਾ ਹੈ।

• Claude Desktop: ਪੂਰਾ OAuth flow ਚਲਾਉਂਦਾ ਹੈ। • Claude API: ਤੁਹਾਨੂੰ ਆਪਣਾ bearer token pass ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। • ChatGPT: ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਲਈ CIMD ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਅਤੇ ਸਭ ਤੋਂ ਨਵੇਂ spec ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। • Gemini: Google Cloud IAM ਅਤੇ API keys ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। • VS Code: GitHub ਅਤੇ Entra providers ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।

ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ ਏਜੰਟ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸਰਵਰ ਦੂਜੇ 'ਤੇ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਵੈਂਡਰ ਪੂਰੇ login flow ਦੀ ਮੰਗ ਕਰ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਦੂਜਾ ਉਮੀਦ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਖੁਦ token ਨੂੰ ਮੈਨੇਜ ਕਰੋ।

ਡਿਵੈਲਪਰਾਂ ਲਈ ਤਿੰਨ ਸਬਕ

  1. Resource Server ਮਾਡਲ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਓ। Identity provider ਬਣਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ। Metadata ਪ੍ਰਦਾਨ ਕਰਨ ਅਤੇ audience ਨੂੰ validate ਕਰਨ ਲਈ RFC 9728 ਦੀ ਵਰਤੋਂ ਕਰੋ।

  2. ਦੋਵਾਂ ਦੁਨੀਆਵਾਂ ਦਾ ਸਮਰਥਨ ਕਰੋ। ਆਪਣੇ ਸਰਵਰ ਨੂੰ "bring your own token" API calls ਅਤੇ ਪੂਰੇ OAuth flows, ਦੋਵਾਂ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਬਣਾਓ।

  3. ਲਗਾਤਾਰ ਅਪਡੇਟਸ ਦੀ ਉਮੀਦ ਰੱਖੋ। Spec ਅਜੇ ਵੀ ਵਿਕਸਿਤ ਹੋ ਰਿਹਾ ਹੈ। OAuth 2.1 ਅਜੇ ਵੀ ਇੱਕ ਡਰਾਫਟ ਹੈ, ਅਤੇ MCP protocol ਅਜੇ ਵੀ ਆਪਣੀ ਜਗ੍ਹਾ ਬਣਾ ਰਿਹਾ ਹੈ।

ਇਸ ਸਮੇਂ MCP ਸਰਵਰ ਬਣਾਉਣਾ ਮੁਸ਼ਕਲ ਹੈ। ਨਿਯਮ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੇ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਲਚਕਦਾਰ ਰਹਿੰਦੇ ਹੋ ਅਤੇ resource server ਮਾਡਲ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਹਨਾਂ ਬਦਲਾਅਾਂ ਵਿੱਚ ਟਿਕ ਸਕਦੇ ਹੋ।

ਸਰੋਤ: https://dev.to/0ndreu/mcp-authentication-in-2026-how-oauth-flipped-the-servers-role-and-why-every-agent-differs-11fm

ਵਿਕਲਪਿਕ ਲਰਨਿੰਗ ਕਮਿਊਨਿਟੀ: https://t.me/GyaanSetuAi