Didit MCP認証：Diditでログイン（OAuth）

Didit MCPはDidit でログイン(OAuth 2.1)で認証します。コンソールでの役割に付与された権限を持つDidit ユーザーとして動作し、APIキーによる認証方式はありません。

Didit でログイン

ホスト型サーバー(https://mcp.didit.me/mcp)はOAuth 2.1のリソースサーバーです。Didit Business Console(business.didit.me)は、同意画面をホストしトークンを発行する認可サーバーです。MCPクライアントは標準のフローを自動的に実行します。

検出

クライアントはトークンなしで/mcpにPOSTし、401とWWW-Authenticate: Bearerヘッダーを受け取ります。このヘッダーのresource_metadataは、保護されたリソースのメタデータ(RFC 9728)を指しています。

https://mcp.didit.me/.well-known/oauth-protected-resource/mcp

このドキュメントには、リソース(https://mcp.didit.me/mcp)、認可サーバー(https://business.didit.me)、およびサポートされるスコープが記載されています。オリジンのルートを先に確認するクライアント向けに、同じドキュメントがhttps://mcp.didit.me/.well-known/oauth-protected-resourceでも提供されています。

登録 (動的クライアント登録)

クライアントはhttps://business.didit.me/.well-known/oauth-authorization-serverで認可サーバーのメタデータを読み取り、まだクライアントIDを持っていない場合はregistration_endpointで自身を登録します(RFC 7591)。お客様側で事前にプロビジョニングするものはありません。ループバックまたはネイティブのコールバックを使うローカルクライアント(Claude Code、Cursor、MCP Inspector)も、審査済みのコールバックを使うクラウドホスト型クライアント(Claude)も、この方法で登録されます。Diditが審査していないリモートのコールバックURLはinvalid_redirect_uriで拒否されます。そのクライアントは、事前にオペレーターによる登録が必要です。

認可 (PKCE)

クライアントはS256のPKCEチャレンジを付けてhttps://business.didit.me/authorizeを開きます。サインイン(または登録)すると、要求されている権限が正確に表示されます。クライアントはパブリッククライアントです。トークンエンドポイントはクライアントシークレットを受け付けない(token_endpoint_auth_methods_supportedはnone)ため、認可コードをクライアントに結び付けるのはPKCEです。

同意

承認すると、コンソールはそのアプリ用に、承認したスコープに紐付いたセッションを発行し、認可コードを返します。クライアントはこのコードをtoken_endpointでアクセストークンとリフレッシュトークンに交換します。

ツールの呼び出し

クライアントはすべてのリクエストにアクセストークンを付けて送信します。MCPはDidit認証サービスに対してRFC 7662のトークンイントロスペクションでトークンを検証し(トークンはJWTではなく不透明なトークンです)、イントロスペクションのレスポンスから組織の権限を読み取り、そのリクエストの間はあなたとして動作します。

スコープ

リソースメタデータは3つのスコープを公開しています。同意画面には、クライアントが要求するスコープがわかりやすい言葉で表示されます。

スコープ	付与される内容
`didit:management`	ワークスペースの管理: `organization`、`members`、`subscription`、`users`、`applications`、`workflows`、`customization`、`questionnaires`、`lists`、`webhooks`、`integrations`、`api-keys`、`audit-logs`、`roles`、`saml`、および`analytics`。
`didit:verification`	認証の実行とレビュー: `sessions`、`businesses`、`cases`、`networks`、`transactions`、`blocklist`、および`analytics`。
`didit:staff`	Diditのスタッフアカウント専用です。通常のアカウントでは何も有効になりません。また、オープンソース版にはスタッフ専用のツールは定義されていません。

どちらのスコープにもanalyticsが含まれます。listsの管理にはdidit:managementが必要で、blocklistへのアクセスにはdidit:verificationが必要です。ツールリファレンスには、各ツールが属するスコープが記載されています。承認したスコープはトークンに含まれ、サーバー側で適用されます。そのため、didit:verificationのみで接続したアプリは、あなた自身の役割では許可される場合でも、管理系の操作を拒否されます。認可サーバーはOpenIDスコープ(openid profile email)にも対応しています。これらのみを要求する接続では、あなたが誰であるかはわかりますが、それ以外の情報にはアクセスできません。アプリの実際の権限は、承認したスコープとコンソールの役割の共通部分です。両者のうち広いほうになることはありません。 didit_session_createで認証セッションを作成するには、didit:verificationスコープかつcreate:sessionsまたはwrite:sessionsを持つ役割が必要です。開発者の役割にはcreate:sessionsが含まれます。didit:managementのみを承認した場合、役割に必要な権限があってもセッションは作成できません。

役割と権限

ホスト型のトークンはあなたを表すため、エージェントは1つの接続であなたが所属するすべての組織にまたがって作業できます。アプリ横断型のツール(didit_session_search、didit_analytics、didit_context_get、およびその他の*_searchツール)は、それらすべての組織を自動的に集計します。あなたの役割は常にDiditのバックエンドによって組織ごとに適用されます。各ツールは1つのバックエンド権限文字列に対応しています(例: didit_session_update_statusにはwrite:sessions、didit_session_deleteにはdelete:sessions)。ツールリファレンスにはツールごとの権限が記載されています。サーバーはリクエストを送信する前にも、イントロスペクションのレスポンスに含まれる組織の権限を使ってその権限を確認します。

enforceモードでは、あなたの役割で実行できないツールはtools/listから除外され、それでも呼び出すと、権限名を示すmissing_scopeエラーが返されます("Your role in this organization does not include the permission 'delete:sessions' that didit_session_delete requires.")。
shadowモード(サーバーのデフォルト)では、すべてのツールが一覧に表示され、呼び出しはバックエンドに送られます。役割に権限がない場合、バックエンドは403を返します。判定結果はサーバーの監査ログに記録されるだけです。

いずれの場合も、MCPがコンソールの役割で既に許可されている範囲を超える権限を付与することはありません。READERは一覧表示と読み取りができ、OWNERまたはADMINは書き込みと削除ができます。

トークンの有効期間

承認されたアプリには、承認に使用したブラウザのセッションとは別の、専用のセッションが付与されます。アクセストークンの有効期間は短く、クライアントはリフレッシュトークンを使って自動的に更新します(grant_types_supportedにはrefresh_tokenが含まれます)。更新後もアプリのスコープは維持され、そのアプリに紐付いたままです。更新に失敗した場合(例えばアプリの接続を解除した後など)、クライアントは次の呼び出し時にDidit でログインを再度実行します。コンソールからサインアウトしても、接続済みのアプリはサインアウトされません。また、アプリを切断しても、どこからもサインアウトされることはありません。

アプリの切断

コンソールから

Settings → Authentication → Connected appsには、承認したすべてのアプリが、登録名と付与された権限とともに一覧表示されます。切断を押すと、そのアプリのアクセスは即座に終了します。アクセストークンとリフレッシュトークンの両方が無効になり、それ以外には影響しません。

アプリから (RFC 7009)

クライアントは、トークンを認可サーバーのrevocation_endpointにPOSTすることで、自身のアクセス権を返却できます。このエンドポイントはhttps://business.didit.me/.well-known/oauth-authorization-serverのメタデータで公開されています。RFC 7009の要件どおり、呼び出しが成功するとトークンがまだ有効だったかどうかにかかわらず200が返るため、レスポンスからトークンが有効だったかどうかを知ることはできません。503は失効を適用できなかったことを意味します。トークンはまだ有効なものとして扱い、再試行してください。

curl -X POST https://business.didit.me/api/auth/oauth-revoke \
  -H "Content-Type: application/json" \
  -d '{"token": "<refresh-or-access-token>", "token_type_hint": "refresh_token", "client_id": "<your-client-id>"}'

APIキーを使わない理由: すべてのMCPツールはユーザー単位のコンソールエンドポイント(/organization/{org}/application/{app}/…)を呼び出します。これらのエンドポイントは役割ごとの権限を持つBearerトークンで認可を行い、x-api-keyを拒否します。アプリケーションのAPIキーは、自社のバックエンドからREST APIを直接呼び出すため(セッションの作成など)のものであり、このMCP用ではありません。didit_org_list_api_keysはキーのメタデータを値を伏せた状態で表示します。生のキーを表示するツールは、ホスト型コネクターでは非表示になっています。

各クライアントからの接続

どのクライアントも同じフローを実行します。異なるのはURLの渡し方だけです。

Claude
Claude Code
Cursor
汎用クライアント

Business Consoleの連携ページに表示されるディープリンクを使用します。このリンクを開くと、Add custom connectorダイアログに値が入力された状態でclaude.aiが開きます。

https://claude.ai/customize/connectors?modal=add-custom-connector&connectorName=Didit&connectorUrl=https://mcp.didit.me/mcp

内容を確認してから、Log in with Diditを完了してください。Claude Desktopでは、Settings → Connectors → Add custom connectorで同じURLを使用します。詳しくはClaudeを接続するをご覧ください。

claude mcp add --transport http didit https://mcp.didit.me/mcp

次に、Claude Code内で/mcpを実行してブラウザでのサインインを開始します。

~/.cursor/mcp.json:

{ "mcpServers": { "didit": { "url": "https://mcp.didit.me/mcp" } } }

Cursorは初回使用時に自身を登録し、ブラウザを開きます。

OAuth 2.1に対応した任意のStreamable HTTPクライアントでhttps://mcp.didit.me/mcpを指定します。クライアントは次の処理を行う必要があります。

POST /mcpを送信して401を受け取り、WWW-Authenticateからresource_metadataを読み取ります。
https://mcp.didit.me/.well-known/oauth-protected-resource/mcpを取得し、続いてhttps://business.didit.me/.well-known/oauth-authorization-serverにある認可サーバーのメタデータを取得します。
クライアントIDを持っていない場合は、registration_endpointで登録します。
authorization_endpointでPKCE (S256)を用いた認可コードフローを実行し、token_endpointでコードを交換します。
すべてのPOST /mcpでAuthorization: Bearer <access_token>を送信します。

OAuthに対応していないクライアントは、npx -y mcp-remote@latest https://mcp.didit.me/mcpを介して利用できます。これがクライアントに代わってステップ1〜5を実行します。

認証エラー

HTTP 401
WWW-Authenticate: Bearer error="invalid_token", error_description="Missing Authorization header", resource_metadata="https://mcp.didit.me/.well-known/oauth-protected-resource/mcp"

/mcpから401が返る場合は、トークンが存在しないか、期限切れか、失効しています。クライアントはトークンを更新するか、Didit でログインをやり直す必要があります。 特定のツールで403またはmissing_scopeエラーが返る場合、通常は接続全体に問題があるのではありません。原因は、ご自身の役割にその権限がない(READERが書き込みを試みた場合など)か、そのツールに必要なスコープなしで接続が承認されたかのどちらかです。後者は、再接続して両方のスコープを承認すれば解決します。前者は役割の変更が必要です。すべてのツールが失敗する場合は、コンソールのSettings → Authentication → Connected appsを確認してください。そこで切断されたアプリは、再度承認する必要があります。

ツールリファレンス

各ツールの機能、スコープ、役割の権限。

高度な設定

役割、アプリ間の動作、セルフホスティング。

ガイド

認証

Model Context Protocol (MCP)

Web SDK

ネイティブSDK

サーバーSDK

連携

Didit MCP認証：Diditでログイン（OAuth）

Didit でログイン

スコープ

役割と権限

トークンの有効期間

アプリの切断

各クライアントからの接続

認証エラー

ツールリファレンス

高度な設定

​Didit でログイン

​スコープ

​役割と権限

​トークンの有効期間

​アプリの切断

​各クライアントからの接続

​認証エラー

ツールリファレンス

高度な設定

Didit でログイン

スコープ

役割と権限

トークンの有効期間

アプリの切断

各クライアントからの接続

認証エラー