Is your feature request related to a problem? Please describe.
When a REST server that signs in users with an authorization code flow and requests a user authorization to let it access an MCP server on the user's behalf, it can acquire an access token with a correct MCP server audience and propagate it with the internal MCP client to access a secured MCP server.
Currently, the MCP authorization specification covers AI assistant like flows where a user login is initiated per every imported secured MCP server in an interactive mode - something that can not work in scope of requests to confidential OIDC clients that run as REST servers and use an AI service with a pre-configured MCP client internally.
Using a client_credentials or other extension grant is sub-optimal in such cases.
Describe the solution you'd like
Make a distinction in the specification between public and confidential OIDC clients.
Specify how a REST server that acts as a confidential OIDC client can request a user authorization to access a secured MCP server, using a scope or a RAR authorization_details.
Describe alternatives you've considered
Using a client_credentials or other extension grants is an option that can work but it is sub-optimal given that an access token with an MCP server audience, acquired upon an authorization code flow completion is already available.
Additional context
N/A
Is your feature request related to a problem? Please describe.
When a REST server that signs in users with an authorization code flow and requests a user authorization to let it access an MCP server on the user's behalf, it can acquire an access token with a correct MCP server audience and propagate it with the internal MCP client to access a secured MCP server.
Currently, the MCP authorization specification covers AI assistant like flows where a user login is initiated per every imported secured MCP server in an interactive mode - something that can not work in scope of requests to confidential OIDC clients that run as REST servers and use an AI service with a pre-configured MCP client internally.
Using a
client_credentialsor other extension grant is sub-optimal in such cases.Describe the solution you'd like
Make a distinction in the specification between public and confidential OIDC clients.
Specify how a REST server that acts as a confidential OIDC client can request a user authorization to access a secured MCP server, using a scope or a RAR
authorization_details.Describe alternatives you've considered
Using a
client_credentialsor other extension grants is an option that can work but it is sub-optimal given that an access token with an MCP server audience, acquired upon an authorization code flow completion is already available.Additional context
N/A