MCP Jam vasitəsilə login və girişin test edilməsi: None, Bearer, OAuth with credentials, Default OAuth

1. MCP Jam avtorizasiya üçün laboratoriya kimi

MCP Jam — bu “daha bir qəribə alət” deyil, MCP‑müştərinin rolunu oynaya bilən laboratoriya stendinizdir. Əslində bu, MCP‑serverlə işləyərkən ChatGPT-nin davranışının emulyatorudur: .well-known/oauth-protected-resource faylını oxuya bilir, OAuth‑axınını işə salır, tokenləri sorğulara əlavə edir və nəyin dəqiq olaraq səhv getdiyini göstərir.

Çox vacib praktik məqam: əgər MCP Jam-də uğurlu Default OAuth axınına nail olmusunuzsa, real ChatGPT App ilə inteqrasiyaya təxminən 80% hazırsınız. ChatGPT hesabı birləşdirərkən (linking) nə edirsə, Jam bunu artıq bacarır, sadəcə daha şəffaf loglar və düymələrlə.

Ötən mühazirədə tədris MCP‑serverimiz GiftGenius üçün baza avtorizasiyanı sazladıq: token yoxlama variantını (JWT və ya introspection) seçdik, .well-known/oauth-protected-resource sənədini və alətləri qoruyan middleware-i reallaşdırdıq. İndi baxacağıq ki, bütün bunlar MCP Jam-də müxtəlif avtorizasiya rejimlərində özünü necə aparır.

Bu mühazirədə məqsədimiz — aşağıdakıları öyrənməkdir:

• Jam-də avtorizasiya rejimlərini şüurlu şəkildə dəyişmək (None, Bearer, OAuth with credentials, Default OAuth);
• Jam-in hər rejimdə MCP‑serverinə nə göndərdiyini anlamaq;
• sistemin hansı hissəsinin sıradan çıxdığını diaqnoz etmək: MCP Server, Auth Server, yoxsa metadata;
• mühafizə olunan alətlərin yalnız tokenlə, açıq alətlərin isə tokensiz də işlədiyini yoxlamaq.

2. Tədris MCP‑serverimiz: nəyi test edirik

Abstrakt danışmamaq üçün qısaca konteksti xatırladaq. Tədris tətbiqimiz GiftGenius ilə davam edirik — bu, hədiyyə seçməyə kömək edən və istifadəçiyə onun sifarişlərini və wish‑list-lərini göstərən bir ChatGPT‑App-dır.

MCP‑server tərəfində bizdə artıq var:

• açıq alət, məsələn, search_gifts — onu anonim çağırmaq olar;
• qorunan alət, məsələn, list_user_orders — o, yalnız autentifikasiya olunmuş istifadəçi üçün işləməlidir və mcp:tools scope tələb etməlidir.

Server bacarır:

• .well-known/oauth-protected-resource dərc etmək;
• tokeni yoxlamaq (JWT və ya introspection vasitəsilə — əvvəlki mühazirədə siz yanaşmalardan birini seçmisiniz);
• tokendən sub (user id), scope, aud götürmək və onları alət handler-lərinə ötürmək.

Node.js/TypeScript-də tipik token yoxlama middleware-i belə görünə bilər:

// middleware/auth.ts
export function requireScope(requiredScope: string) {
  return async (req: any, res: any, next: () => void) => {
    const header = req.headers["authorization"];
    if (!header?.startsWith("Bearer ")) {
      res
        .status(401)
        .set(
          "WWW-Authenticate",
          `Bearer realm="mcp", resource_metadata="${process.env.BASE_URL}/.well-known/oauth-protected-resource", scope="${requiredScope}"`
        )
        .json({ error: "unauthorized" });
      return;
    }

    // burada artıq tokeni yoxlayırsınız (imza, exp, aud, scope...)
    // və nəticəni req.user-ə yerləşdirirsiniz
    next();
  };
}

Bu middleware MCP-nin qorunan alətlərindən əvvəl istifadə olunacaq. Token yoxdursa — 401 və spesifikasiyanın tələbinə uyğun WWW-Authenticate başlığını resource_metadata ilə qaytarırıq. Token yoxlamasının detallı izahını və köməkçi funksiyaların reallaşdırılmasını siz artıq əvvəlki mühazirədə etmisiniz, burada bunu hazır kimi qəbul edirik.

3. MCP Jam-də avtorizasiya rejimləri: icmal

MCP Jam-də MCP‑serverə qoşulmaq üçün bir neçə avtorizasiya rejimi var. Onlar tipik OAuth nümunələrinə uyğundur: tokenin tam yoxluğundan tutmuş tam Authorization Code + PKCE-yə qədər.

Qısa siyahı:

1. None (No Auth) — Jam ümumiyyətlə Authorization başlığını əlavə etmir. Bu, anonim girişdir. Açıq MCP‑serverlər və qorunan resursların düzgün 401 və WWW-Authenticate ilə imtina etməsini yoxlamaq üçün uyğundur.
2. Bearer Token — Jam Authorization: Bearer <token> əlavə edir, siz onu interfeysə əl ilə daxil edirsiniz. Sürətli yoxlamalar üçün uyğundur: token artıq hardasa (curl, Keycloak UI) alınıb və siz MCP resursunun davranışını yoxlamaq istəyirsiniz.
3. OAuth with credentials (Client Credentials) — Jam göstərilən Client ID və Secret-dən istifadə edərək Auth Server-dən client_credentials vasitəsilə tokeni özü alır. Bu, “məxfi müştəri” rejimidir, daha çox istifadəçi iştirakı olmadan server‑server avtorizasiyasına bənzəyir.
4. Default OAuth (Authorization Code + PKCE) — ChatGPT‑tipli müştərilər üçün əsas rejimdir (sirr olmadan public client). Jam resource_metadata-nı oxuyur, Auth Server-i tapır, /authorize ilə brauzeri açır, PKCE axınını aparır və istifadəçi tokeni alır.

Anlaşıqlı olsun deyə bunu cədvəldə toplayaq.

İndi hər rejimi ayrıca nəzərdən keçirək və GiftGenius MCP‑serverimizi onun üzərindən necə keçirdiyimizi baxaq.

4. None rejimi: serverin düzgün imtina etdiyini yoxlayırıq

Ən primitiv rejimdən başlayaq: heç bir avtorizasiya yoxdur.

MCP Jam-də serverinizi seçirsiniz (məsələn, http://localhost:4000/mcp) və bağlantı ayarlarında avtorizasiya rejimini None edirsiniz.

Bu zaman nə baş verir:

• Jam MCP‑bağlantısı qurur;
• alət çağırıldıqda o, Authorization başlığını əlavə etmir;
• istənilən açıq alətləri (məsələn, search_gifts) çağıra bilərsiniz;
• qorunan alət çağırıldıqda (məsələn, list_user_orders) serveriniz 401 Unauthorized qaytarmalıdır.

Vacibdir ki, bu 401 ilə server düzgün WWW-Authenticate başlığını əlavə etsin. OpenAI və MCP Authorization spesifikasiyasının tövsiyəsinə yaxın, realm və scope kimi əlavə sahələr olan cavab nümunəsi:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="mcp",
  resource_metadata="https://giftgenius.example.com/.well-known/oauth-protected-resource",
  scope="mcp:tools"
Content-Type: application/json

{"error": "unauthorized"}

Jam belə cavabı görəndə anlayır: resurs qorunur, metadata-nı haradan götürmək lazımdır (resource_metadata) və hansı scope-lar gözlənilir. None rejimində sadəcə xətanı göstərəcək, amma Default OAuth rejimində göstərilən resource_metadata üzrə avtomatik gedəcək və OAuth‑axınını işə salacaq.

Sazlama baxımından, None rejimində siz yoxlayırsınız:

• açıq alətlərin ümumiyyətlə tokensiz işlədiyini;
• qorunan alətlərin heç vaxt anonim icra olunmadığını;
• WWW-Authenticate başlığının spesifikasiyaya uyğun olduğunu (Bearer və resource_metadata daxil olduğunu).

Bu, triviyal yoxlama kimi səslənsə də, problemlərin böyük hissəsi ondadır ki, 401 WWW-Authenticate olmadan və ya orada səhv parametr ilə qaytarılır (məsələn, aktual resource_metadata əvəzinə köhnə resource_metadata_uri).

5. Bearer Token rejimi: Resource Server məntiqinin sürətli testi

Növbəti addım — sizdə artıq (Jam-dən kənarda alınmış) etibarlı token var və siz xüsusi olaraq Resource Server məntiqini yoxlamaq istəyirsiniz: server həmin tokeni düzgün qəbul/imtina edirmi, scope və audience ilə düzgün işləyirmi və sub-u servisinizin istifadəçisi ilə düzgün bağlayırmı.

MCP Jam-də rejimi Bearer Token edirsiniz və token sahəsinə, məsələn, bunları daxil edirsiniz:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

İndi Jam hər MCP‑sorğusuna belə başlıq əlavə edəcək:

Authorization: Bearer eyJhbGciOi...

MCP‑serveriniz sorğunu qəbul edir, requireScope("mcp:tools") middleware-indən keçir, JWT-ni dekodlayır və claims yoxlayır. Yoxlamanın tipik kodunu sadələşdirilmiş formada belə yazmaq olar:

// auth/verifyToken.ts
import jwt from "jsonwebtoken";

export function verifyToken(header: string) {
  const token = header.replace("Bearer ", "");
  const payload = jwt.verify(token, process.env.JWT_PUBLIC_KEY!);
  // burada aud, scope və s. yoxlana bilər
  return payload as { sub: string; scope?: string };
}

Və bunu middleware-də istifadə etmək:

// requireScope daxilində
const payload = verifyToken(header);
if (!payload.scope?.includes(requiredScope)) {
  res.status(403).json({ error: "insufficient_scope" });
  return;
}
(req as any).user = { id: payload.sub };
next();

Bearer rejimində siz eksperiment edə bilərsiniz:

• lazımi scope olmadan token daxil edib, serverin 403/401 cavabı verdiyini görmək;
• səhv aud ilə token daxil edib, serverin onu rədd etdiyini yoxlamaq;
• vaxtı bitmiş token daxil edib, invalid_token xəta cavabını görmək.

Bu, UI‑login və PKCE iştirak etmədən Resource Server məntiqinin lokal “sürətli testi” rejimidir. Burada yoxladıqlarınızın hamısı sonradan Default OAuth rejimində ChatGPT və ya Jam tərəfindən alınan tokenlərə eyni ilə tətbiq olunur.

6. OAuth with credentials (Client Credentials) rejimi: “tətbiq adından” token

İndi — daha nadir, amma anlamaq üçün faydalı rejim: OAuth with credentials, yəni client_credentials grant. Jam-də siz göstərirsiniz:

• Client ID
• Client Secret
• lazımi scopes (məsələn, mcp:tools)

Jam Auth Server-in token_endpoint-inə təxminən bu cür sorğu göndərir:

POST /oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&
client_id=<ID>&
client_secret=<SECRET>&
scope=mcp:tools

Auth Server token verir, burada sub adətən konkret istifadəçini deyil, elə müştərini bildirir (məsələn, sub = "mcp-jam-test-client"). Jam bu tokeni adi Bearer kimi istifadə etməyə başlayır.

MCP dünyasında bu nə üçün faydalı ola bilər:

• konkret istifadəçiyə bağlanmayan servis/admin alətləri (məsələn, logların çıxarılması, health‑check, texniki dəstək);
• MCP‑serverin, əgər biznes məntiqiniz bunu nəzərə alırsa, istifadəçi tokenləri ilə “müştəri” tokenlərini fərqləndirməyi bacardığını yoxlamaq.

ChatGPT Apps kontekstində bu rejim adətən istifadə olunmur, çünki ChatGPT ictimai müştəri kimi sirr saxlamır (public client-in client_secret olmamalıdır). Amma Jam-də o, aşağıdakılar arasındakı fərqi görməyə kömək edir:

• “Sadəcə hazır tokeni təqdim etdim” (Bearer rejimi);
• “Jam tokeni müştəri rekvizitləri ilə özü aldı” (OAuth with credentials).

Tədris serverində, məsələn, yalnız grant_type=client_credentials və uyğun rolla gələn tokenlə əlçatan olan xüsusi MCP‑alət admin_list_all_orders yarada bilərsiniz. Bu, bu günün mühazirəsi üçün məcburi deyil, amma faydalı bir təcrübədir.

7. Default OAuth rejimi: ChatGPT-də olduğu kimi tam Authorization Code + PKCE

İndi — proqramın əsas ulduzu: Default OAuth. Məhz bu rejim App hesabınızı bağlayarkən ChatGPT-nin etdiklərinə ən çox bənzəyir. Müştəri resource_metadata-nı oxuyur, Auth Server-ə gedir, istifadəçiyə login səhifəsini açır, authorization code alır və onu Authorization Code + PKCE S256 sxemi ilə access token-ə dəyişir.

Addımların ardıcıllığını açaq. Aydın olması üçün — diaqram.

sequenceDiagram
    participant Jam as MCP Jam (Client)
    participant RS as MCP Server (Resource)
    participant PRM as /.well-known/oauth-protected-resource
    participant AS as Auth Server (Keycloak/Auth0)
    
    Jam->>RS: Qorunan alətin çağırışı (tokensiz)
    RS-->>Jam: 401 + WWW-Authenticate (resource_metadata=PRM)
    Jam->>PRM: GET /.well-known/oauth-protected-resource
    PRM-->>Jam: resource, authorization_servers, scopes_supported ilə JSON...
    Jam->>AS: GET /authorize?client_id=...&code_challenge=...&scope=...
    Note right of AS: İstifadəçi daxil olur və razılıq verir
    AS-->>Jam: authorization_code ilə redirect
    Jam->>AS: POST /token (code + code_verifier)
    AS-->>Jam: { access_token, scope, expires_in, ... }
    Jam->>RS: Authorization: Bearer <access_token> ilə alətin çağırışı
    RS-->>Jam: Alətin uğurlu nəticəsi

Bu rejimdə sizin üçün vacib yoxlamalar:

1. MCP‑serverdən düzgün 401/WWW-Authenticate cavabı. Server resource_metadata vermirsə və ya səhv URL verirsə, Jam PRM-i oxuya bilməyəcək və OAuth‑axınını başlada bilməyəcək.
2. Etibarlı .well-known/oauth-protected-resource sənədi. Orada resource, authorization_servers, scopes_supported və s. düzgün olmalıdır ki, Jam tokenləri haradan almağı və hansı scope-ları istəməyi anlaya bilsin.
3. Auth Server-in düzgün sazlanması.
   • Authorization Code Flow PKCE S256 ilə aktivdir.
   • Client ID PRM-də gözlənilənlə üst-üstə düşür (və ya DCR — Dynamic Client Registration vasitəsilə qeydiyyatdan keçirilir).
   • Auth Server-də Redirect URI Jam-in istifadə etdiyi ilə dəqiq üst-üstə düşür.
4. PKCE S256. Jam code_challenge formalaşdırır və Auth Server-in S256 metodunu dəstəkləməsini gözləyir. Əgər PKCE söndürülübsə və ya yalnız plain dəstəklənirsə, axın dağılacaq.
5. Scopes və audience. Auth Server lazımi aud və tələb olunan scope-larla (mcp:tools və s.) token verməlidir, MCP‑server isə bunları yoxlamalıdır.

Uğurlu Default OAuth nəticəsində siz əldə edəcəksiniz:

• Jam-də MCP‑serverlə qoşulmanı, burada qorunan alət list_user_orders məhz Auth Server-də daxil olduğunuz istifadəçi üçün düzgün məlumatları qaytarır;
• Auth Server loglarında uğurlu authorize + token mübadiləsi;
• MCP‑server loglarında tokenin uğurlu təsdiqi və sub-un çıxarılması.

Sazlama üçün tez-tez alət handler-inə sadə logger əlavə etmək kömək edir ki, token-dən userId-i həqiqətən gördüyünüzə əmin olasınız:

// list_user_orders MCP alətinin handler-i daxilində
export async function listUserOrders(args: any, context: any) {
  const user = context.user as { id: string };
  console.log("[MCP] listUserOrders for user", user.id);
  // sonra bu istifadəçinin sifarişlərini qaytarırsınız
}

8. Harada nə sıradan çıxır: rejimlər üzrə diaqnostika

İndi isə gəlin MCP Jam-dəki simptomlara görə problemin dəqiq harada olduğunu necə başa düşəcəyimizi müzakirə edək: MCP‑serverdə, Auth Server-də, yoxsa metadata-da. Bu bölmə rejimlər üzrə bir növ diaqnostika yoxlama siyahısıdır.

Əgər None rejimində:

Qorunan aləti çağırırsınız, server aşağıdakıları qaytarır:

• 200 OK və token olmadan belə əməliyyatı yerinə yetirir — deməli, bu alətdən əvvəl sizdə token yoxlaması yoxdur. Middleware və ya scope yoxlaması əlavə etmək lazımdır.
• 401, amma WWW-Authenticate olmadan və ya problemli resource_metadata ilə — Jam metadata-nı haradan götürəcəyini anlamayacaq və Default OAuth-u başlada bilməyəcək. Başlığı yuxarıdakı nümunəyə görə düzəldin.

Əgər Bearer Token rejimində:

• Jam əmin olduğunuz etibarlı tokenlə belə stabil olaraq 401/403 alır (məsələn, curl və ya Postman ilə birbaşa çağırdığınızda işləyir). Çox güman, Resource Server məntiqində nəsə səhvdir: aud/scope yanlış yoxlanır və ya JWT imzası üçün səhv public açardır.
• Əgər Bearer token Jam-də işləyir, amma sonradan Default OAuth-da işləmir — deməli, problem MCP‑serverdə deyil, Auth Server və ya PRM-dədir: Default OAuth ilə alınan token sizin əl ilə test etdiyiniz tokenlə scope/aud baxımından fərqlənir.

Əgər OAuth with credentials rejimində:

• Jam tokeni ala bilmirsə (/token addımında xəta) — səbəbi Auth Server-dəki müştəri sazlamalarında axtarın (səhv secret, client_credentials icazə verilməyib və ya scope qadağandır).
• Token var, amma MCP‑server onu rədd edirsə — bəlkə də serveriniz istifadəçi sub-unu (email/istifadəçi ID-si) gözləyir, token-də isə yalnız müştərinin identifikatoru var. Yaxud aud/scope gözlənilənlərlə uyğun gəlmir.

Əgər Default OAuth rejimində:

Bu, ən çox “gizli daş” olan ssenaridir. Tez-tez rast gəlinən problemlər:

• Səhv redirect URI-ləri. Auth Server invalid_redirect_uri ilə şikayətlənir və ya sadəcə kod vermir. Jam-in URI-sinin IdP müştəri sazlamalarında əlavə edildiyinə və artıq slash və ya yazı səhvi olmadığına əmin olun.
• PKCE-nin olmaması və ya dəstəklənməməsi. Əgər Auth Server PKCE tələb edir, Jam (və ya onun köhnə versiyası) code_challenge göndərmirsə, və ya əksinə — Jam S256 göndərir, amma IdP bu metodu dəstəkləmir, siz invalid_request görəcəksiniz.
• Uyğunlaşmayan scope-lar. PRM-də siz mcp:tools bəyan etmisiniz, amma IdP-də müştəriyə yalnız openid icazə verilib, və ya əksinə — Jam IdP-nin verməyə hazır olduğundan daha çox scope istəyir.
• Yanlış audience (aud). Token MCP‑serverin gözlədiyindən fərqli aud ilə verilir (məsələn, başqa resursun URL-i). Server onu haqlı olaraq rədd edəcək.

Üç yerdəki loglara baxmağı öyrənmək çox vacibdir:

• MCP Jam — PRM oxunarkən və Auth Server-ə HTTP sorğularında xətalar;
• Auth Server — /authorize və /token logları nədən imtina etdiyini göstərəcək;
• MCP‑server — tokenin rədd edilmə səbəbləri (invalid_token, insufficient_scope, wrong_audience).

9. Bunun real ChatGPT App ilə bağlantısı

Niyə Jam ilə bu qədər vaxt keçiririk, dərhal ChatGPT-nin Developer Mode-na qaçmırıq? Çünki Jam məhz laboratoriya stendidir: o, sizə avtorizasiya rejimlərinə nəzarət verir və axının bütün daxili “mətbəxini” göstərir.

Jam-də Default OAuth-u işə salıb uğura çatdıranda, faktiki olaraq təsdiq edirsiniz ki:

• MCP‑serverdə .well-known/oauth-protected-resource düzgündür;
• Auth Server (Keycloak/Auth0/…) düzgün sazlanıb;
• rollar, scope-lar, audience və claims gözləntilərə uyğundur;
• MCP‑server tokeni yoxlamağı və onu istifadəçi ilə bağlamağı bacarır.

Eyni MCP‑serverə qoşulan ChatGPT də eyni şeyi edəcək: PRM-i oxuyacaq, Auth Server-ə gedəcək, token alacaq və alətləri Authorization: Bearer ilə çağırmağa başlayacaq.

Fərq ondadır ki, ChatGPT-də siz yalnız yekun nəticəni görürsünüz (“hesabı uğurla bağladınız” və ya “nəsə alınmadı”), Jam-də isə bütün protokolu görür və addım-addım “nəyin” və “harada” alınmadığını anlaya bilirsiniz.

10. Mini‑praktika: GiftGenius MCP‑serverimizi ardıcıl test edirik

Hamısını layihənizdə təkrarlaya biləcəyiniz sadə ardıcıllıqda toplayaq.

Əvvəlcə MCP‑serverinizi işə salın (məsələn, pnpm dev:mcp), əmin olun ki:

• o, http://localhost:4000/mcp (və ya sizin URL) ünvanında dinləyir;
• /.well-known/oauth-protected-resource endpoint-i düzgün JSON qaytarır;
• Auth Server (Keycloak) işləyir və Jam/ChatGPT üçün sazlanmış public‑client var.

Sonra:

1. None rejimi.
   Jam-i MCP‑serverə avtorizasiyasız qoşursunuz. Yoxlayırsınız ki:
   • search_gifts işləyir;
   • list_user_orders düzgün 401 və WWW-Authenticate qaytarır.
2. Bearer Token rejimi.
   Keycloak vasitəsilə access token alın (UI və ya curl). Jam-ə qoyun, list_user_orders-u çağırın və əmin olun ki:
   • etibarlı tokenlə alət işləyir və konkret istifadəçinin sifarişlərini qaytarır;
   • mcp:tools olmadan və ya fərqli aud ilə token olduqda — server xəta qaytarır.
3. OAuth with credentials rejimi.
   Əgər məxfi müştəriniz varsa: Jam-də client_id və client_secret göstərin, lazım olan scope-u qoyun, texniki aləti (məsələn, admin_list_all_orders) çağırın və yalnız belə servis tokeni ilə işlədiyini yoxlayın.
4. Default OAuth rejimi.
   Default OAuth-u aktiv edin, list_user_orders-u çağırın. Jam özü:
   • 401 + WWW-Authenticate alacaq,
   • PRM-i oxuyacaq,
   • brauzeri açacaq və siz Keycloak-a daxil olacaqsınız,
   • Authorization Code + PKCE ilə token alacaq,
   • tokenlə MCP‑aləti çağıracaq və siz cavabda öz sifarişlərinizi görəcəksiniz.

Bu dörd rejimin hamısı gözlənildiyi kimi işləyibsə — təbriklər, siz təkcə “Keycloak-la nəsə quraşdırmadınız”, həqiqətən bütün auth‑axını necə yoxlamağı və sazlamağı öyrəndiniz.

11. MCP Jam və avtorizasiya testində tipik səhvlər

Praktik həyatda bu problemlər tez-tez təkrarlanan xəta nümunələri şəklində üzə çıxır. Aşağıda — “necə etməmək olar” tipli bir neçə tipik ssenari var ki, simptomlarına görə onları tanıya biləsiniz.

Səhv №1: qorunan alətin None rejimində işləyəcəyini gözləmək.
Bəzən developer Jam-i None rejimində açır, list_user_orders-u çağırır və 401-ə təəccüblənir, sonra da “birdən” serverdə token yoxlamasını çıxarır. Nəticədə MCP‑alət anonim işləməyə başlayır ki, bu, şəxsi məlumatlar və commerce ssenariləri üçün qətiyyən yolverilməzdir. None rejimi məhz bunun üçün lazımdır: serverin tokensiz düzgün imtina etdiyini və resource_metadata ilə WWW-Authenticate qaytardığını yoxlamaq.

Səhv №2: unudulmuş və ya səhv WWW-Authenticate başlığı.
Çox yayılan hal: server 401 qaytarır, amma WWW-Authenticate yoxdur və ya köhnəlmiş resource_metadata_uri parametrindən istifadə olunur. Bu halda Jam (və ChatGPT) Protected Resource Metadata-nı haradan götürəcəyini anlamır və Default OAuth ümumiyyətlə başlamır. Minimal yetərli variant — WWW-Authenticate: Bearer resource_metadata="https://.../.well-known/oauth-protected-resource". realm və scope sahələri ixtiyaridir; əsas məsələ resource_metadata-nı unutmaq deyil.

Səhv №3: yalnız Bearer rejimini test edib, Default OAuth-u görməməzlikdən gəlinməsi.
Developer tokeni əl ilə alır, Jam-ə qoyur, hər şeyin işlədiyini görür və işi bitmiş sayır. Amma real ChatGPT-ni qoşmaq vaxtı gələndə məlum olur ki, .well-known düzgün deyil, PKCE dəstəklənmir, redirect URI uyğun gəlmir və linking uğursuz olur. Bearer rejiminin testi vacib, amma kifayət deyil. Default OAuth-u mütləq keçmək lazımdır, əks halda Auth Server və PRM-in ən vacib sazlamalarının yarısını yoxlamamış olursunuz.

Səhv №4: istifadəçi tokeni lazım olan yerdə client_credentials-dan istifadə cəhdi.
Bəzən developer ümidsizlikdən Jam-də OAuth with credentials rejimini aktiv edir və client_credentials ilə tokenlər almağa başlayır, sonra isə onları list_user_orders kimi istifadəçi alətləri üçün istifadə edir. Nəticədə token-dəki sub real istifadəçi deyil, client_id olur və biznes məntiqi qəribə davranır (məsələn, “ümumi” məlumatları göstərir və ya həmin ID-li istifadəçini tapmağa çalışarkən düşür). Real istifadəçilərlə ChatGPT ssenariləri üçün Authorization Code + PKCE (Default OAuth) lazımdır, client_credentials yalnız servis tapşırıqları üçün uyğundur.

Səhv №5: PRM, Auth Server və MCP‑server arasında scope və audience uyğunsuzluğu.
.well-known/oauth-protected-resource-da siz resursu https://giftgenius.example.com kimi göstərmisiniz və dəstəklənən scope-lar — ["mcp:tools"]. Auth Server müştəriyə aud olmadan token verib, MCP‑server isə tokeni yoxlayarkən dəqiq aud = "https://giftgenius.example.com" və mcp:tools olmasını gözləyir. Nəticədə Default OAuth ilə alınan token MCP‑server tərəfindən rədd edilir və siz “sehr” axtarmağa yarım gün sərf edirsiniz. Həmişə PRM, IdP-də müştəri konfiqi və MCP‑server middleware yoxlamasının audience və scope üzrə bir-biri ilə razılaşdırıldığına əmin olun.

Səhv №6: MCP Jam-in köhnə versiyasından istifadə.
MCP Authorization spesifikasiyası aktiv inkişaf edir, yeni sahələr peyda olur (resource_metadata, təkmilləşdirilmiş PKCE axını, köməkçi sazlayıcılar). Əgər sizdə Jam-in köhnə versiyasıdırsa, o, yeni sahələri başa düşməyə və ya köhnəlmiş parametr adları ilə işləməyə bilər. Bu isə sürreal xətalara gətirir: hər şeyi son RFC-yə görə sazlamısınız, amma Jam sadəcə bununla nə edəcəyini bilmir. Ümidsizliyə qapılmadan əvvəl Jam-in aktual versiyaya yeniləndiyinə əmin olun.