@@ -51,13 +51,37 @@ while maintaining simplicity:
5151 that do not support Authorization Server Metadata ** MUST** follow the default URI
5252 schema.
5353
54- ### 2.2 Basic OAuth 2.1 Authorization
54+ ### 2.1.1 OAuth Grant Types
55+
56+ OAuth specifies different flows or grant types, which are different ways of obtaining an
57+ access token. Each of these targets different use cases and scenarios.
58+
59+ MCP servers ** SHOULD** support the OAuth grant types that best align with the intended
60+ audience. For instance:
61+
62+ 1 . Authorization Code: useful when the client is acting on behalf of a (human) end user.
63+ - For instance, an agent calls an MCP tool implemented by a SaaS system.
64+ 2 . Client Credentials: the client is another application (not a human)
65+ - For instance, an agent calls a secure MCP tool to check inventory at a specific
66+ store. No need to impersonate the end user.
67+
68+ ### 2.2 Example: authorization code grant
69+
70+ This demonstrates the OAuth 2.1 flow for the authorization code grant type, used for user
71+ auth.
72+
73+ ** NOTE** : The following example assumes the MCP server is also functioning as the
74+ authorization server. However, the authorization server may be deployed as its own
75+ distinct service.
76+
77+ A human user completes the OAuth flow through a web browser, obtaining an access token
78+ that identifies them personally and allows the client to act on their behalf.
5579
5680When authorization is required and not yet proven by the client, servers ** MUST** respond
5781with _ HTTP 401 Unauthorized_ .
5882
5983Clients initiate the
60- [ OAuth 2.1 IETF DRAFT] ( https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12 )
84+ [ OAuth 2.1 IETF DRAFT] ( https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#name-authorization-code-grant )
6185authorization flow after receiving the _ HTTP 401 Unauthorized_ .
6286
6387The following demonstrates the basic OAuth 2.1 for public clients using PKCE.
0 commit comments