Enterprise-Managed Authorization: say how the Resource Authorization Server gets the IdP's signing keys
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 45/100
- issue の種類
- ドキュメント
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
調査の方向性
Start with section 5.1 and the referenced ID-JAG §4.4.1, then compare the OpenID Connect Discovery and RFC 8414 metadata requirements. Done means the specification explains how the Resource Authorization Server obtains signing keys and includes the proposed User-Agent guidance, with the origin, rotation, and multi-tenant questions resolved.
索引モデルが issue の本文から書いたものです。
説明
Problem
Section 5.1 sends ID-JAG processing to §4.4.1 of draft-ietf-oauth-identity-assertion-authz-grant-04, which requires a valid signature. Neither document says how the Resource Authorization Server finds the IdP's signing keys. The draft assumes the Resource Authorization Server already trusts the IdP, but trusting an issuer doesn't tell you where its keys are.
We implement this extension in Notion's hosted MCP server and have tested it against several IdPs. Each implementation has to choose, on its own:
- how to find the keys (
jwks_urifrom OpenID Connect Discovery, from RFC 8414 metadata, or configured by hand); - whether
jwks_urimust be on the issuer's origin; - when to refetch keys after rotation;
- how to handle multi-tenant issuers.
One failure from our testing shows the cost. An IdP behind a CDN web application firewall returned 403 to our JWKS fetch, because the library making it sent no User-Agent. Our discovery fetch to the same host sent one and got 200. Nothing in the spec chain told either side what to expect. (Library fix: cloudflare/workers-oauth-provider#394.)
Proposal
Additive, no breaking changes. In section 5.1:
- The Resource Authorization Server SHOULD get the IdP's signing keys from the
jwks_uriin the metadata for the ID-JAG'siss, found with OpenID Connect Discovery 1.0 or RFC 8414. - A non-normative note: metadata, JWKS, and Client ID Metadata Document fetches are ordinary HTTP requests, so they SHOULD include a
User-Agentper RFC 9110 §10.1.5. IdPs commonly sit behind firewalls that block requests without one.
Open questions
- Should rule 1 live here, or in the ID-JAG draft so it covers non-MCP uses too?
- Should
jwks_urihave to share the issuer's origin? We require it today. It narrows where keys can come from, but some IdPs may host keys on a separate domain. - Is refetch-on-unknown-
kidguidance for key rotation in scope?
This looks to us like a clarification that doesn't need a SEP. We're happy to follow the SEP process if the maintainers prefer, and to send a PR with the wording.
- 主要言語
- MDX
- スター
- 165
- フォーク
- 54
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
modelcontextprotocol/ext-auth のほかの issue
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
modelcontextprotocol/ext-auth#32 · コメント 1 件 ·
-
DEBUGオープンbug
難易度 5/5 1週間以上 初心者へのやさしさ 10/100
-
Add Authorization Flow for MCP client server hosts extension対応中かも @sberyozkin が 182 日前に担当しました。 オープンenhancement
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
modelcontextprotocol/ext-auth#26 · コメント 1 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 35/100
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
modelcontextprotocol/ext-auth#21 · コメント 1 件 ·
modelcontextprotocol/ext-auth の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
doorkeeper-gem/doorkeeper-openid_connect#409 · コメント 1 件 ·
-
conda skeleton cran has SSL_NO_VERIFY check inverted and TLS verification off by default対応中かも @matthewfeickert が今日担当しました。 オープンtype::bug
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
conda/conda-build#6202 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
OpenHands/automation#565 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
Chorus-AIDLC/Chorus#604 ·
メンテナーはふだん 1 日以内に返信
-
area:auth bug
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
メンテナーはふだん 1 日以内に返信