Hi all, Currently we don't have the facility of using OpenID Connect Discovery to get the OpenID Provider information needed to interact with it, including its OAuth 2.0 endpoint locations. I have implemented this facility for IS, as it is described at [1]. The implemented code can be found at [2]. This will help in solving the "Discovery Problem" [3] of the Service Provider.
As described at the specification [4], it has two main services to be provided by the Identity Server side in order to implement the OpenID Connect Discovery. 1. Web Finger Service for OpenID Provider Issuer Discovery 2. An endpoint to provide OpenID Provider Configuration These two services are independent. The final target of the process is to get the OpenID Provider Configuration metadata, such as issuer, authorization_endpoint, token_endpoint, userinfo_endpoint etc. (as further described in the [1]). The respond will be a json document including all the configuration. For this to happen the service provider should SOMEHOW know the endpoint which provide OpenID Provider Configuration. Web Finger Service is ONE way of doing this. So, in the Service Provider point of view the service required from the first service may be optional. If the service provider has to request the Web Finger Service to get to know OpenID Provider Issuer the end point of the Web Finger Service should be known by the user. This is required to be done by an identifier provided by the end-user. This identifier is normalized by the service provider to find out the Web Finger host, where the users OpenID Provider Issuer can be discovered. [1] Or else the Service Provider, based on its application design, may require the users' OpenID Provider Configuraiton to be found at one place. (Ex: When there is no federation). Or a browser plugin instead of user may provide this to the Service Provider. However, AFAIU this matter is upto the Service Provider to decide.[4] >From the Identity Server point of view it is noteworthy to point that there is no connection between these two services and their responds. The designed architecture and workflow is further discussed in [1]. [1] https://docs.google.com/document/d/10WGDzCBSCk6DPeiUNcvLbZIzmyDAMkQLJ-TUHJi104E/ [2] https://github.com/ChamaraPhilipsuom/carbon-identity/tree/OpenID-Connect-Discovery [3] http://hareendracsespace.blogspot.com/2015/12/the-discovery-problem.html [4] https://openid.net/specs/openid-connect-discovery-1_0.html Any suggestions and ideas for improving this feature is highly welcome. Thanks & Regards -- Hareendra Chamara Philips *Software Engineer* Mobile : +94 (0) 767 184161 <%2B94%20%280%29%20773%20451194> [email protected] <[email protected]>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
