Repository navigation
Replies: 5 comments 3 replies
|
Hi @tnorimat When I raised a question to the OpenId4VCI authors, whether OpenId4VCI could also reference the OpenID connect well-known location, I got a reply that RFC8414 section 5 was written 8 years ago. So at some point the "transition period" should be considered that is over. In any case, I believe that KC should align with RFC8414 well-known requirements. |
|
@babisRoutis Hello, Yes, we can resolve the issue by using a proxy, but it might be better that Keycloak itself can resolve it. |
|
Dear @tnorimat Perhaps my previous comment was not clear. I fully agree with your proposal |
|
According to the merged PR, which allows to use OIDC Discovery specified server metadata, Keycloak might not need to follow RFC 8414 defining well-known endpoint URI for MCP in the next version of MCP. |
|
Although, this discussion was triggered by the MCP case, I think that compliance to RFC 8414 well-known convention should be considered independently. Numerous other specifications (like for instance OpenId4VCI) require this and do not reference OIDC Discovery |
|
Yes, I know OID4VCI also requires RFC 8414 well-known convention. |
|
The corresponding issue is created #40923 |
Uh oh!
There was an error while loading. Please reload this page.
Idea
The current Keycloak's Well-Known URI for Authorization Server Metadata does not follow RFC 8414 OAuth 2.0 Authorization Server Metadata. So how about following the RFC?
Motivation
One of the motivation for complying with RFC 8414 is to use Keycloak as an authorzation server in an AI agent system applying Model Context Protocol (MCP). The MCP specification requires an authorization server to comply with RFC 8414.
According to the MCP specification, an MCP client accesses the Well-Known URI complying RFC 8414 to get an authorzation server to get its authorization server metadata. If we use the current Keycloak as an authorization server in an AI agent system applying MCP, an MCP client fails to get Keycloak's authorization server metadata.
Situation
For example, consider the situation where we create a realm named "issuer1",
The issuer URL of keycloak:
https://keycloak.example.com/realms/issuer1 .
The current Keycloak's Well-Known URI for Authorization Server Metadata:
https://keycloak.example.com/realms/issuer1/.well-known/oauth-authorization-server
RFC 8414 compliant Well-Known URI for Authorization Server Metadata:
https://keycloak.example.com/.well-known/oauth-authorization-server/realms/issuer1
Authorization Server Metadata
According to Section 3 of RFC 8414, the transformation algorithm from the issuer URL to the Well-Known URL is as follows:
Also, Section 3.1 of RFC 8414 states that:
OpenID Server Metadata
Regarding OpenID Server Metadata, the current Keycloak complies with OpenID Connect Discovery 1.0
The issuer URL of keycloak:
https://keycloak.example.com/realms/issuer1 .
The current Keycloak's Well-Known URI for OpenID Server Metadata:
https://keycloak.example.com/realms/issuer1/.well-known/openid-configuration
OIDC Discovery compliant Well-Known URI for OpenID Server Metadata:
https://keycloak.example.com/realms/issuer1/.well-known/openid-configuration
According to Section 4.1 of OIDC Discovery, the transformation algorithm from the issuer URL to the Well-Known URL is as follows:
Compatibility Notes
Section 5 of RFC 8414 states the compability between RFC 8414 and OIDC Discovery as follows:
Solution
Regarding the current Keycloak, its Authorization Server Metadata and its OpenID Server Metadata are the same. Therefore, the possible solution is to return its Authorization Server Metadata from the following both Well-Known URIs:
The current Keycloak's Well-Known URI for Authorization Server Metadata:
https://keycloak.example.com/realms/issuer1/.well-known/oauth-authorization-server
RFC 8414 compliant Well-Known URI for Authorization Server Metadata:
https://keycloak.example.com/.well-known/oauth-authorization-server/realms/issuer1
All reactions