Skip to content

SEP-837: Update authorization spec to clarify client type requirements #837

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
mcp-commander merged 15 commits into from
Mar 28, 2026
+30 −0
Merged

SEP-837: Update authorization spec to clarify client type requirements #837

Changes from all commits
Commits
Show all changes
15 commits
Select commit Hold shift + click to select a range
946995a
Update authorization.mdx
localden Jun 24, 2025
63e0277
Update authorization.mdx
localden Jun 24, 2025
290197a
Update docs/specification/draft/basic/authorization.mdx
localden Jul 4, 2025
855718f
Apply suggestion from @nbarbettini
localden Jul 4, 2025
6240d21
Update authorization.mdx
localden Jul 4, 2025
5c6f6fc
Merge branch 'main' into localden/authz-clienttype
localden Jul 4, 2025
b1651e8
Merge branch 'main' into localden/authz-clienttype
dend Aug 20, 2025
cff70c5
Update docs/specification/draft/basic/authorization.mdx
localden Sep 23, 2025
af7138e
docs: address review feedback on application_type guidance
dend Mar 4, 2026
4bea765
Merge main into localden/authz-clienttype
dend Mar 4, 2026
c88b3a2
Update docs/specification/draft/basic/authorization.mdx
localden Mar 10, 2026
4291fa5
Strengthen application_type requirement to MUST per review feedback
localden Mar 10, 2026
7462351
Merge branch 'main' into localden/authz-clienttype
localden Mar 10, 2026
1ecb5b4
Fix prettier formatting in SEP docs
localden Mar 10, 2026
f9e9ef9
Merge branch 'main' into localden/authz-clienttype
localden Mar 28, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 30 additions & 0 deletions docs/specification/draft/basic/authorization.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,6 +35,7 @@ while maintaining simplicity:
([RFC7591](https://datatracker.ietf.org/doc/html/rfc7591))
- OAuth 2.0 Protected Resource Metadata ([RFC9728](https://datatracker.ietf.org/doc/html/rfc9728))
- OAuth Client ID Metadata Documents ([draft-ietf-oauth-client-id-metadata-document-00](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-00))
- OpenID Connect Dynamic Client Registration 1.0 ([OpenID Connect Registration](https://openid.net/specs/openid-connect-registration-1_0.html))

## Roles

Expand Down Expand Up @@ -330,6 +331,35 @@ OAuth 2.0 Dynamic Client Registration Protocol [RFC7591](https://datatracker.iet
to allow MCP clients to obtain OAuth client IDs without user interaction.
This option is included for backwards compatibility with earlier versions of the MCP authorization spec.

#### Application Type and Redirect URI Constraints

When authorization servers support OpenID Connect (OIDC) and
Dynamic Client Registration, they may enforce additional
constraints on redirect URIs based on the `application_type`
parameter as defined in
[OpenID Connect Dynamic Client Registration 1.0](https://openid.net/specs/openid-connect-registration-1_0.html).

MCP clients **MUST** specify an appropriate `application_type`
during Dynamic Client Registration. Omitting it defaults to
`"web"` under OIDC, which can conflict with native-style redirect
URIs; non-OIDC servers safely ignore the parameter.

- **Native applications** (desktop applications, mobile apps,
CLI tools, and locally-hosted web applications accessed via
`localhost`) **SHOULD** use `application_type: "native"`
- **Web applications** (remote browser-based applications
served from a non-local host) **SHOULD** use
`application_type: "web"`

MCP clients **MUST** be prepared to handle registration
failures due to redirect URI constraints when authorization
servers implement OIDC. When a registration request is rejected,
clients **SHOULD** surface a meaningful error to the user or
developer. Clients **MAY** retry registration with an adjusted
`application_type` or with redirect URIs that conform to the
authorization server's requirements for the given application
type.

## Scope Selection Strategy

When implementing authorization flows, MCP clients **SHOULD** follow the principle of least privilege by requesting
Expand Down
Loading