MCP avtorizasiyasının arxitekturası: MCP Client, MCP Server, MCP Auth Server

1. Bu mühazirə nədən bəhs edir və nələr yoxdur

Bu çox maraqlı bir mühazirə olacaq; bu mühazirədə biz:

• MCP Client, MCP Server və MCP Auth Server arasında “etimad üçbucağı”nı başımızda canlandırırıq — bu üçbucağın “üzərində” resursların sahibi kimi dayanan insan‑istifadəçi ilə birlikdə;
• flow-u dilə gətiririk: kim kimə token göndərir, istifadəçi harada login olur və niyə MCP server heç vaxt onun parolunu görmür;
• bunu bizim Next.js/MCP backend-imiz və gələcək Keycloak/Auth0 sazlaması ilə əlaqələndiririk.

Bu gün etmədiklərimiz:

• Keycloak-da “quş” işarələri klikləmirik və konkret IdP qurmuruq;
• tam JWT yoxlaması və ya introspection yazmırıq — bunlar növbəti mühazirələrin mövzusudur (Auth Server və qorunan resurs kimi MCP Server haqqında).

Məqsəd indi — siz kağız götürüb ChatGPT, serveriniz və Auth0/Keycloak arasında oxlarla sxem çəkə biləsiniz və tərəddüd etmədən izah edəsiniz: login haradadır, token haradadır, məlumat haradadır.

2. Etimad üçbucağı: MCP Client, MCP Server, MCP Auth Server

Gəlin iştirakçılardan başlayaq. Texniki “etimad üçbucağı”nı MCP Client, MCP Server və MCP Auth Server formalaşdırır; istifadəçi (User) — resurs sahibi olan ayrıca roldur, sanki bu üçbucağın üzərində dayanır və çıxışa razılıq verir. MCP və Apps SDK spesifikasında bu arxitektura kifayət qədər dəqiq formallaşdırılıb.

User (Resource Owner)

Bu, ekranın o tərəfində olan insandır. O:

• ChatGPT-yə daxil olur;
• “mənim sifarişlərimi / hədiyyə siyahılarımı göstər” kimi sorğu yazır;
• xidmətinizin hesabını ChatGPT-yə “bağlamağa” razı olur.

Əsas məqam: məhz o, resursların (sifariş tarixi, profillər, hədiyyə siyahıları) sahibidir və məhz o, onlara çıxışa razılıq verir.

MCP Client

Burada bizim üçün bunlardır:

• Apps SDK ilə ChatGPT;
• bəzən — MCP Jam Inspector (debug zamanı).

MCP Client bacarır:

• sizin MCP serverinizin metadatasını oxumağı (.well-known vasitəsilə);
• istifadəçinin brauzerində OAuth‑flow-u işə salmağı;
• tokenləri saxlayıb MCP alətlərinə çağırışlara əlavə etməyi.

Yadda saxlamaq vacibdir ki, MCP Client — public client-dir. O, sizin client_secret-i saxlamır, buna görə Auth Server ilə public SPA tətbiqi kimi ünsiyyət qurur: Authorization Code + PKCE.

MCP Server (Resource Server)

Bu, MCP-ni reallaşdıran sizin backend-dir:

• ChatGPT ilə əlaqə qurur;
• alətləri (tools), resursları, promtları elan edir;
• hər alət çağırışında Authorization: Bearer <token> başlığını yoxlayır;
• tokeni (imza, exp, aud, scope) yoxlayır və hər şey qaydasındadırsa, biznes məntiqini icra edir.

Prinsipial məqam: MCP server loginlə məşğul olmur. O, parolları görmür, login forması çəkmir, istifadəçiyə “email-i təsdiqləyin” məktubu göndərmir. O, yalnız Auth Server-dən kriptoqrafik imzalanmış tokenlərə etibar edir.

MCP Auth Server (Authorization Server / IdP)

Bu, ayrıca autentifikasiya və avtorizasiya xidmətidir: Keycloak, Auth0, Ory Hydra+Kratos, Okta, Cognito, Azure AD və s.

O, bunlara cavabdehdir:

• login UI-si (email/parol, SSO, 2FA);
• istifadəçi hesablarının saxlanması;
• tokenlərin verilməsi (access token, refresh token);
• OAuth/OIDC metadatalarının dərc edilməsi (/authorize, /token, jwks_uri, /registration və s.).

MCP üçün o, public clients üçün OAuth 2.1-i dəstəkləməlidir (PKCE S256, dynamic client registration və s.).

Rolların xülasə cədvəli

Əgər beyninizdə bunların hamısı “hər şeyi edən böyük server” kimi qarışırdısa — artıq ayırmağın vaxtıdır.

3. Flow necə görünür: “token yoxdur”dan alətlərin qorunan çağırışına qədər

İndi mesaj axınına baxaq. MCP spesifikasında bu proses “The Flow” adlanır: discovery → redirect → code → token → authorized calls.

Addım 0. Token olmadan qorunan aləti çağırmağa cəhd

İstifadəçi yazır: “Yadda saxladığım hədiyyə ideyalarını göstər”.

MCP Client kimi ChatGPT qərar verir: “bunun üçün bizim MCP serverdə getUserGiftLists alətini çağırmaq lazımdır”. O, token olmadan çağırış edir (axı istifadəçi hələ login olmayıb).

Sizin MCP serveriniz:

• Authorization başlığının yoxluğunu və ya səhv olmasını görür;
• 401 Unauthorized cavablandırır və WWW-Authenticate: Bearer resource_metadata="https://api.giftgenius.com/.well-known/oauth-protected-resource" başlığını əlavə edir — qorunan resursun metadatasına (resource metadata, bu haqda aşağıda) istinadla.

Bu təxminən belədir (məntiq, tam HTTP deyil):

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://api.giftgenius.com/.well-known/oauth-protected-resource"

ChatGPT bu başlığı görür və anlayır: “aha, resurs OAuth ilə qorunub, OAuth‑flow-u yerinə yetirmək və hesabı bağlamaq lazımdır”.

Discovery: .well-known/oauth-protected-resource

Sonra MCP Client serverinizdən metadata soruşur:

GET /.well-known/oauth-protected-resource

Server resurs identifikatoru və tokenlərin alınmalı olduğu avtorizasiya serverlərinin siyahısı ilə JSON sənədi qaytarır.

Minimum nümunə (detallarını sonra sazlayacağıq, indi ideya vacibdir):

{
  "resource": "https://api.giftgenius.com",
  "authorization_servers": [
    "https://auth.giftgenius.com"
  ],
  "scopes_supported": ["gifts.read", "gifts.write"]
}

Burada:

• resource — resursunuzun kanonik ID-si; sonra token verilişində audience və ya resource kimi istifadə olunmalıdır;
• authorization_servers — ChatGPT-nin token istəyə biləcəyi Auth Server-lərin siyahısı;
• scopes_supported — MCP serverinizin ümumiyyətlə başa düşdüyü “hüquqlar”.

Authorization Request: Auth Server-ə redirect

Metadata əldə edildikdən sonra MCP Client Auth Server-ə gedir. O, brauzerdə bir tab açır:

GET https://auth.giftgenius.com/authorize
    ?response_type=code
    &client_id=chatgpt-giftgenius
    &redirect_uri=... (MCP Client-in geri dönmə URL-i)
    &code_challenge=...
    &code_challenge_method=S256
    &scope=openid gifts.read
    &resource=https://api.giftgenius.com

İstifadəçi:

• tanış login ekranını görür (məsələn, Keycloak və ya Auth0);
• login/parolu daxil edir, 2FA-dan keçir;
• ChatGPT-nin onun hədiyyə siyahılarını oxumasına icazə verir (gifts.read scope-u).

Code → Token: kodun PKCE ilə tokenə dəyişdirilməsi

Uğurlu login-dən sonra Auth Server istifadəçini code ilə MCP Client-ə geri redirect edir. MCP Client:

• /token-ə POST edir;
• code və yuxarıdakı addımda olan code_challenge-a uyğun gələn code_verifier ötürür.

Auth Server PKCE-ni yoxlayır: code_verifier-i həşləyir, ilkin code_challenge ilə müqayisə edir. Hər şey qaydasındadırsa və flow-u həqiqətən eyni client başlayıbsa, o:

• qısaömürlü access_token verir (adətən JWT);
• onda göstərir:
  • sub — Auth Server-də istifadəçinin ID-si;
  • aud və ya resource — sizin MCP serveriniz;
  • scope — icazə verilən əməliyyatlar (gifts.read, openid və s.).

Authenticated Request: MCP alətinin tokenlə çağırılması

İndi MCP Client alətinizi yenidən çağırmağa hazırdır, amma bu dəfə başlıqla:

Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

MCP server:

• tokenin imzasını (Auth Server-in JWK-si ilə) və ya introspection vasitəsilə yoxlayır;
• etibarlılıq müddətini (exp) yoxlayır;
• aud / resource-a baxır — tokenin həqiqətən https://api.giftgenius.com üçün verildiyini təsdiqləyir;
• scope-a baxır və getUserGiftLists-i çağırmağın mümkün olub-olmadığına qərar verir.

Bundan sonra o, artıq DB-nizə hər hansı bir userId üzrə gedir və şəxsi hədiyyə siyahılarını qaytarır.

Diqqət edin ki, bu ana qədər biz yalnız şəbəkə flow-u haqqında danışdıq: token necə alınır və MCP serverə çatdırılır. Sonra vacibdir başa düşmək ki, tokenin sub və digər claims-lərindən sizin DB-də konkret userId necə alınır — burada “identity bridge” oyuna daxil olur.

4. Identity Bridge: ChatGPT istifadəçisi DB-nizdə userId-a necə çevrilir

Arxitekturanın ən maraqlı hissəsi — “identiklik körpüsü”dür (identity bridge). MCP spesifikasında birbaşa vurğulanır: MCP server ChatGPT istifadəçilərini bilmir, o, Auth Server-dən gələn tokenin məlumatlarına əsaslanır.

Sxem təxminən belədir:

flowchart TD
  User[ChatGPT-də User] -->|Login/SSO| Auth[Auth Server]
  Auth -->|JWT: sub, email, tenant| MCP[MCP Server]
  MCP -->|userId/tenantId| DB[(Sizin verilənlər bazası)]

Addım-addım bu belə görünür.

Birincisi, Auth Server daxilində istifadəçilərini tanıyır: onda user, email, id, bəlkə də tenant, roles kimi obyektlər var. Uğurlu login zamanı bu məlumatı tokenə (claims-ə) yerləşdirir:

{
  "sub": "auth0|abc123",
  "email": "user@example.com",
  "given_name": "Alice",
  "https://giftgenius.com/tenant": "tenant-42",
  "scope": "openid gifts.read",
  "aud": "https://api.giftgenius.com"
}

İkincisi, MCP Server tokeni yoxlayarkən bu claims-ləri götürür və bunun onun dünyasında kim olduğunu müəyyənləşdirir. Məsələn:

• əgər sub artıq User.authProviderId cədvəlindədirsə — əlaqəli userId-i götürürük;
• əgər yoxdursa — lokal yazı yaradırıq (on‑the‑fly provisioning) və əlaqələndiririk.

MCP server tərəfində tipik bir TypeScript kod parçası (sadələşdirilmiş, imza yoxlaması olmadan) belə görünə bilər:

type TokenClaims = {
  sub: string;
  email?: string;
  scope?: string;
};

async function mapClaimsToUserId(claims: TokenClaims): Promise<string> {
  const user = await db.user.findUnique({ where: { authSub: claims.sub } });
  if (user) return user.id;

  const created = await db.user.create({
    data: { authSub: claims.sub, email: claims.email ?? null }
  });
  return created.id;
}

Üçüncüsü, artıq öz userId-iniz üzrə MCP server lazım olan hər şeyi götürür: hədiyyə siyahıları, sifariş tarixi, sazlamalar, tarif.

Beləliklə, Auth Server xarici dünya (ChatGPT, Google, SSO) ilə sizin daxili dünyanız (customer_id — sifariş DB-də) arasında “körpü”yə çevrilir.

5. Niyə Auth Server və MCP Server ayrı olmalıdır

Belə bir cazibə yarana bilər: “Gəlin elə mənim MCP serverim həm login göstərsin, həm də token versin”. Formal olaraq bu mümkündür (içinə mini IdP qura bilərsiniz), amma arxitektura baxımından pis fikirdir. Səbəblər kifayət qədər praktiki-dir.

Birincisi, təhlükəsizlik və miqyaslana bilmə. Auth Server ağır maşındır: 2FA, social login, parol siyasətləri, hesabın bloklanması, girişin bərpası, giriş auditi, bəlkə də sertifikatlaşdırmalar. Bunu hər mikroxidmətdə (hər MCP serverdə) təzədən yazmaq — çıxılmaz yoldur. Bunu Keycloak/Auth0-a həvalə etmək və sadəcə onların tokenini yoxlamaq xeyli asandır.

İkincisi, müştərinin dəyişə bilməsi. Bu gün yalnız ChatGPT-niz var. Sabah Claude Desktop-u, Next.js-də öz veb frontend-inizi, mobil tətbiqi qoşacaqsınız. Onların hamısı eyni Auth Server və eyni OAuth 2.1 sxemindən istifadə edə bilər, MCP serveriniz isə sadəcə tokenləri yoxlamağa davam edər. Yeni müştəri üçün biznes məntiqini yenidən yazmağa ehtiyac olmayacaq.

Üçüncüsü, kodun təmizliyi. İdealda MCP Server:

• /.well-known/oauth-protected-resource dərc edə bilir;
• Bearer tokeni yoxlaya və ondan userId, scopes, tenant çıxara bilir;
• biznes alətlərini reallaşdırır (orders, gifts, profiles).

Bütün login UI məntiqi — formalar, layout, sosial loginlər — Auth Server-də yaşayır və backend-i yükləmir.

6. Bu, bizim tədris tətbiqimiz GiftGenius-da necə görünür

Kurs boyu apardığımız tətbiqə qayıdaq. Tutaq ki, bizdə var:

• hədiyyələri seçməyi bacaran widget-lı (Apps SDK) “GiftGenius” adlı ChatGPT App;
• alətləri təqdim edən Node/Next.js-də MCP server:
  • searchGifts — anonimdir, login tələb etmir;
  • getSavedGiftLists — şəxsi, autentifikasiya tələb edir;
• Hər istifadəçinin hesabı olan Auth Server (sonra — Keycloak/Auth0).

Anonim və login olmuş istifadəçi ssenarisi

İstifadəçi sadəcə “qardaş üçün hədiyyə seç, 30 yaş, stolüstü oyunları sevir” yazırsa, App-ımız:

• anonim searchGifts alətini çağırır;
• interfeysdə tövsiyələr verir.

Bu halda:

• token lazım deyil;
• MCP server sadəcə sorğunu icra edir (məsələn, kataloqunuz və ya üçüncü tərəf API-si ilə).

İstifadəçi “bunu mənim siyahılarıma saxla” və ya “yadda saxladığım ideyaları göstər” dediyi anda model qorunan getSavedGiftLists alətini çağırmağa qərar verir. Server 401 + WWW-Authenticate və resource_metadata ilə cavab verir. ChatGPT “Link GiftGenius account” OAuth veryazını işə salır, istifadəçini login-dən keçirir və token alır.

Sonra hər qorunan çağırışda:

• MCP Server artıq Authorization: Bearer ... görür;
• token-dən userId-i çıxarır;
• məlumatları həmin userId üzrə filtr edir.

Məhz bunun sayəsində biz:

• fərqli istifadəçilərin məlumatlarını ayıra bilirik;
• sifariş tarixini, seçilmişləri təhlükəsiz şəkildə göstərə bilirik;
• commerce funksiyalarını həyata keçiririk (kursda sonra).

Backend arxitekturası: middleware + alət handler-ləri

Praktikada Node/Next.js kodunda bu çox vaxt belə görünür: “middleware autentifikasiya → alətin biznes handler-i”. Alət handler-lərinin reallaşdırılması mühazirəsində artıq vurğulamışdıq ki, onlara kontekst ötürmək lazımdır: user_id, tokenlər, sazlamalar.

Kod fraqmenti belə ola bilər:

// auth-context.ts
export type AuthContext = {
  userId: string | null;    // tokensiz çağırışlar üçün null
  scopes: string[];
};

Bütün MCP endpoint-lərinə asılan middleware:

// mcp-auth-middleware.ts
export async function buildAuthContext(req: Request): Promise<AuthContext> {
  const header = req.headers.authorization || "";
  const token = header.replace(/^Bearer\s+/i, "");

  if (!token) return { userId: null, scopes: [] }; // anonim istifadəçi

  const claims = await verifyAndDecodeToken(token); // tokenin verifikasiyası
  const userId = await mapClaimsToUserId(claims);
  const scopes = (claims.scope || "").split(" ");
  return { userId, scopes };
}

Alətin öz handler-i bu konteksti alır:

// tools/getSavedGiftLists.ts
export async function getSavedGiftLists(_args: {}, ctx: AuthContext) {
  if (!ctx.userId) throw new Error("User must be authenticated");

  return db.giftList.findMany({
    where: { ownerId: ctx.userId }
  });
}

Məna ondadır ki, alət handler-i nə OAuth, nə PKCE barədə heç nə bilmir. O, sadəcə “aydın” userId ilə işləyir. Bütün OAuth “sehr”i ondan əvvəl gizlədilib: MCP client-də və Auth middleware-də.

7. Vizual sxemlər: Client, Server və Auth birlikdə necə yaşayır

Flow-u 3-cü bölmədə addım-addım mətnlə izah etdik. Bəzən bir dəfə çəkmək yeddi dəfə izah etməkdən asandır, ona görə indi eyni qarşılıqlı əlaqələri iki diaqram şəklində göstərək.

Əlaqənin skeleti (The Triangle of Trust)

flowchart TD
  U[User] -->|1. Login / Consent| A[MCP Auth Server]
  U -->|2. Söhbətləşir| C["MCP Client (ChatGPT)"]
  C -->|3. OAuth Flow| A
  C -->|4. Bearer Token| S[MCP Server]
  S -->|5. Data| C

Sxem belə oxunur.

Əvvəlcə istifadəçi Auth Server vasitəsilə login olur, o da əslində onun şəxsiyyətini təsdiqləyir və token verir. MCP Client bu prosesi idarə edir və sonra tokeni MCP serverə müraciət etmək üçün istifadə edir. MCP server login/parolu görmür, yalnız token görür və icazəni o müəyyən edir.

Sorğudan cavaba qədər axın

sequenceDiagram
  participant User
  participant ChatGPT as MCP Client
  participant Auth as Auth Server
  participant MCP as MCP Server

  User->>ChatGPT: "Hədiyyə siyahılarımı göstər"
  ChatGPT->>MCP: callTool(getSavedGiftLists) (tokensiz)
  MCP-->>ChatGPT: 401 + WWW-Authenticate (resource_metadata)
  ChatGPT->>Auth: /authorize + PKCE
  User->>Auth: Login/parolu daxil edir, razılıq verir
  Auth-->>ChatGPT: redirect + code
  ChatGPT->>Auth: /token + code_verifier
  Auth-->>ChatGPT: access_token (JWT)
  ChatGPT->>MCP: callTool(getSavedGiftLists) + Authorization: Bearer ...
  MCP-->>ChatGPT: şəxsi siyahıların JSON-u
  ChatGPT-->>User: Widgetdə göstərilən siyahı

Bu diaqram — modulun sonunda “gözünüz qapalı” danışa bilməli olduğunuz şeydir.

8. Bir neçə resurs, bir neçə müştəri, DCR: bir az dərinlik

Belə arxitekturanın gözəlliyi — o, miqyaslana bilir.

Birincisi, sizdə bir neçə MCP server ola bilər (məsələn, biri hədiyyələr, digəri sifarişlər üçün) və bir Auth Server, hansı ki, müxtəlif aud/resource ilə tokenlər verir. Hər bir resurs‑server tokenin həqiqətən onun üçün verildiyini yoxlamalıdır, əks halda klassik “confused deputy” problemi alınacaq — yəni bir xidmət üçün verilən token digər xidmət tərəfindən qəbul ediləcək.

İkincisi, sizdə çoxlu müştəri ola bilər:

• ChatGPT App;
• öz frontend-iniz;
• mobil tətbiq;
• MCP Gateway vasitəsilə tərəfdaş inteqrasiyası.

Onların hamısı:

• /.well-known/oauth-protected-resource-u oxuyacaq;
• Auth Server-in harada olduğunu öyrənəcək;
• OAuth 2.1 flow-dan keçəcək;
• token alacaq və MCP serverə çağırış edəcək.

Üçüncüsü, müasir Auth Server-lər getdikcə daha çox Dynamic Client Registration (DCR)-i dəstəkləyir — müştəriləri API ilə dinamik qeydiyyatdan keçirmək imkanı. MCP spesifikasiyası məhz bu imkanı nəzərdə tutur: müştəri (ChatGPT/Jam) özünü Auth Server-də onun registration_endpoint-i vasitəsilə avtomatik qeydiyyatdan keçirə bilər.

Bu modulda bizim üçün vacib olan budur ki:

• MCP Client, MCP Server və Auth Server standartlaşdırılmış discovery sənədləri və tokenlər vasitəsilə ünsiyyət qurur;
• backend kodunda bütün müştəriləri “sərt şəkildə yazmağa” ehtiyac yoxdur;
• mövcud avtorizasiya modelini pozmadan ekosistemi genişləndirə bilərsiniz.

9. MCP avtorizasiya arxitekturasını anlamaqda tipik səhvlər

Səhv №1: “MCP server istifadəçini özü login etməlidir”.
Bəzən tərtibatçılar login formasını birbaşa MCP serverə yerləşdirməyə çalışır və sonra login/parolu alətlər vasitəsilə göndərirlər. Bu, OAuth ideyasını pozur. MCP server heç bir halda parolu görməməlidir. Login və consent — Auth Server-in məsuliyyət sahəsidir. MCP server yalnız tokenlərlə və onların claims-ləri ilə işləyir.

Səhv №2: MCP Client və MCP Server arasında qarışıqlıq.
Bəzən ChatGPT-ni “mənim backend-im”in hissəsi kimi qəbul edirlər və məsələn, orada hansısa sirlər saxlamağa çalışırlar və ya onun özünün giriş hüquqlarını yoxlayacağını gözləyirlər. Əslində MCP Client yalnız OAuth-u başladır və tokenləri əlavə edir. Tokenin və hüquqların yoxlanması — ChatGPT-nin deyil, MCP serverin işidir.

Səhv №3: .env-də “API açarı” əvəzinə OAuth.
Klassik anti-pattern: böyük bir SERVICE_API_KEY düzəltmək, onu MCP serverin .env-nə qoymaq və problemin həll olunduğunu düşünmək. Bu variantda istifadəçilər üzrə hüquqların ayrılması yoxdur, şəxsi məlumatları təhlükəsiz göstərmək və ya alış etmək mümkün deyil, hər şey “xidmətin adından” edilir, istifadəçinin deyil. Bu, ChatGPT App-lərində avtorizasiyanın məqsədlərinə tam ziddir.

Səhv №4: audience və resource-un nəzərə alınmaması.
Əgər MCP server uyğun imzalı istənilən etibarlı JWT-ni qəbul edirsə və aud/resource-a baxmırsa, onda eyni Auth Server tərəfindən başqa xidmət üçün verilən istənilən token sizin alətlərinizin çağırılması üçün istifadə oluna bilər. Bu, OAuth təhlükəsizlik modelinin birbaşa pozulmasıdır. Server mütləq tokenin məhz onun resource-u üçün verildiyini yoxlamalıdır.

Səhv №5: auth məntiqi ilə biznes məntiqinin qarışdırılması.
Bəzən alət handler-lərinə tokenin açılıb oxunması, imzanın yoxlanması, JWK ilə iş və s. kimi bütün auth işlərini daşımağa başlayırlar. Nəticədə kod kövrək və çətin saxlanılan olur. Daha düzgün yol — “tokenin yoxlanması, userId-a xəritələnməsi” qatını (middleware) “alətin məhz məntiqi” qatından ayırmaqdır; sonuncu artıq anlaşılan AuthContext alır.

Səhv №6: .well-known olmadan ChatGPT-nin “hər şeyi özü edəcəyini” gözləmək.
Düzgün /.well-known/oauth-protected-resource endpoint-i olmadan MCP client sadəcə Auth Server-in harada olduğunu və hansı scope-ların lazım olduğunu bilmir. Nəticə — çat səssizcə “login edə bilmir”, tərtibatçı isə boş loglara baxır. Düzgün yol: MCP server avtorizasiya tələblərini .well-known vasitəsilə aydın şəkildə elan edir, client onları oxuyur və flow qurur.

Səhv №7: Biznes məntiqində unudulmuş istifadəçi.
Bəzən OAuth və tokenin userId-a xəritələnməsini düzgün qurduqdan sonra belə, tərtibatçılar bunu DB sorğularında istifadə etmirlər: məsələn, ownerId = userId üzrə filtr etməyi unudurlar. Onda istənilən autentifikasiya olunmuş istifadəçi başqasının məlumatlarını görə bilər. Tokenin mövcudluğu — yalnız birinci addımdır; ikinci addım həmişə userId və scope-un biznes kodunda düzgün istifadəsidir.