Auth: MCP Servers are Resource Servers only. Add Protected Resource Metadata to discover Authorization Server #338
Conversation
dsp-ant
force-pushed
the
davidsp/auth-rs-as-prm
branch
from
075bc17 to
df2ebe8
Compare
dsp-ant
force-pushed
the
davidsp/auth-rs-as-prm
branch
from
df2ebe8 to
63095fb
Compare
dsp-ant
force-pushed
the
davidsp/auth-rs-as-prm
branch
from
63095fb to
b8b98cb
Compare
There was a problem hiding this comment.
The link for the OAuth 2.0 Protected Resource Metadata in section 2.3.1 points to the draft. (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-metadata-13)
Shouldn't it be https://datatracker.ietf.org/doc/html/rfc9728 instead?
|
I already fixed that in #402 |
Oops! Sorry about that! |
|
I think it would be good to add more context around the refresh token. I can see it is shown in the flow and the specification mentions that refresh token handling best practices should be used. I feel it might be better to mention in which cases a refresh token should be used, otherwise the client could unnecessarily have indefinite access. It would be better to provide a reference to refresh token handling best practices (maybe https://datatracker.ietf.org/doc/html/rfc9700#name-refresh-token-protection). Also noticed that the specification directly mentions the authorization code grant and the client credentials grant but doesn't have a mention of the refresh token grant although the refresh token is referenced. |
|
The specification does not mention how the WWW-Authenticate header should look like. A sample would be useful. Thanks |
dsp-ant
changed the title
No description provided.