MCP OAuth Client Credentials vs Authorization Code: який flow обрати

Обирайте authorization code, коли MCP client діє від імені конкретної людини: користувач входить, бачить consent, а token представляє делеговане право на визначений MCP resource. Обирайте OAuth Client Credentials extension, коли ініціатором є workload — scheduler, CI job, daemon або backend service — і в операції немає користувача, чию згоду треба представити. API key не є третім рівноцінним flow: це довгоживучий shared secret без стандартної token audience, discovery та scope lifecycle.

Головне питання не «де простіше отримати token», а «чия authority виконує дію». Authorization code не треба маскувати під service account через технічного користувача, а client credentials не можна використовувати для непомітної підміни user consent. Якщо workflow іноді запускає людина, а іноді automation, моделюйте два principals і дві policy paths, навіть якщо вони викликають той самий MCP tool.

• Людина присутня і делегує доступ → authorization code + PKCE.
• Workload працює без людини → OAuth Client Credentials extension.
• Локальний stdio server → credentials із захищеного host environment, не HTTP OAuth flow.
• Один tool для user і service → різні principals, scopes, budgets та audit labels.
• Наслідкова дія → окремий policy gate незалежно від authentication.

Authorization code з PKCE прив'язує grant до user interaction і підходить desktop, web та conversational clients, де користувач має зрозуміти ресурс і requested scopes. Protected Resource Metadata та authorization-server discovery допомагають знайти правильний issuer; resource indicator і audience validation обмежують token конкретним MCP server. Scope challenge дозволяє просити додаткове право лише тоді, коли operation його справді потребує.

Client credentials представляє application, а не людину. Офіційна MCP extension називає background services, CI/CD, server-to-server integrations і daemons типовими сценаріями. Вона підтримує client secret або JWT bearer assertion; documentation рекомендує assertion, коли це можливо, бо private signing key не передається token endpoint. Проте workload усе одно потребує owner, мінімальних scopes, rotation, egress policy і kill switch.

• Principal → user subject для authorization code; application subject для client credentials.
• Interaction → browser/consent потрібні першому flow; другий працює headless.
• Credential → PKCE-bound code проти secret або signed JWT assertion.
• Revocation → user grant lifecycle проти workload credential lifecycle.
• Audit → actor + client + user проти service + job/run + owner.

Client ID, client metadata і client credential відповідають на питання, який client звертається до authorization server; grant type відповідає на питання, чиє право він отримує. У delegated flow confidential client може мати власний secret або private_key_jwt і водночас використовувати authorization code від імені user. Сам факт наявності client secret не перетворює цей flow на client credentials.

У MCP 2026-07-28 для interactive authorization пріоритетні pre-registration і Client ID Metadata Documents; Dynamic Client Registration лишився backward-compatible fallback. Це не скасовує окрему Client Credentials extension. Реєструйте allowed grant types явно, не дозволяйте одному client_id довільно перемикатися між user і workload authority, а credentials прив'язуйте до перевіреного authorization-server issuer.

Для обох flows MCP server перевіряє signature або introspection result, issuer, audience/resource, expiry і required scopes. Client credentials token не має user subject, тому server не повинен вигадувати tenant або owner із tool argument. Service-to-tenant mapping зберігається в authorization data, а high-risk tools можуть бути недоступними workload principals або вимагати signed job context і зовнішнє approval.

Scope — це coarse capability, не завершена бізнес-авторизація. `invoices.write` не відповідає, до якої legal entity, суми або стану invoice є доступ. Після token validation policy engine перевіряє object ownership, environment, parameters, time window, budget і separation of duties. MCP server ніколи не пересилає отриманий MCP token до downstream API: для upstream system він отримує окремий audience-bound credential.

Для client credentials простий client secret зберігайте в secret manager, видавайте конкретному workload і регулярно ротувайте; не вбудовуйте його в repository, container image, prompt або MCP configuration, яку може прочитати модель. JWT bearer assertion з коротким `exp`, унікальним `jti` та правильною `aud` зменшує передачу long-lived secret, але private key усе одно потребує захищеного signing boundary та rotation.

Access tokens кешуйте за issuer, client, resource і scope set, ніколи не між tenants або environments. На revocation чи deployment rollback зупиняйте нові token requests, відкликайте або ротувайте credential і завершуйте in-flight consequential actions через reconciliation. Старий pod не повинен зберігати authority лише тому, що token ще формально не expired.

Delegated path тестуйте на redirect URI substitution, PKCE downgrade, issuer mix-up, consent bypass, excessive scopes, token theft і cross-user cache. Workload path — на leaked secret, replay assertion, wrong token-endpoint audience, unauthorized grant type, cloned deployment, cross-environment credential reuse та job context spoofing. Для обох обов'язкові wrong MCP audience, expired token, insufficient scope, tenant mismatch і token passthrough.

Failure має бути fail-closed і діагностичним. `invalid_token`, `insufficient_scope` та domain-policy denial — різні стани; automation не повинна відповідати на них нескінченним refresh або scope escalation. Audit записує decision ID, principal type, workload, issuer, resource, scopes, tool, hashed job/run reference і outcome без token, secret або повного assertion.

Почніть з inventory MCP tools і позначте allowed principal types: user-only, workload-only або both. Далі створіть окремі clients, scopes і policy rules для interactive та headless lanes. Проведіть negative tests, запустіть read-only workload canary, виміряйте denial/retry/token-refresh signals, а writes відкривайте лише після idempotency, exact-action constraints і authoritative postcondition check.

Rollback для delegated lane вимикає client або scope, відкликає grants і повертає попередню policy version. Для workload lane додатково зупиняє scheduler/deployment, ротирує credential і звіряє незавершені job outcomes. Спільний dashboard показує token failures, scope challenges, denied tools, credential age, issuer/audience mismatch і consequential actions за principal type — без змішування user activity з automation.