Closed mshaheerimran closed 2 years ago
This organization is not maintained anymore besides critical security bugfixes (if feasible). This organization will be archived when .NET Core 3.1 end of support is reached (3rd Dec 2022). All new development is happening in the new Duende Software organization.
The new Duende IdentityServer comes with a commercial license but is free for dev/testing/personal projects and companies or individuals making less than 1M USD gross annnual revenue. Please get in touch with us if you have any question.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Questions are community supported only and the authors/maintainers may or may not have time to reply. If you or your company would like commercial support, please see here for more information.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Hi Identity Server team,
We are dealing with an Identity Server built on Duende ID Server v5 (managed by another team) and an ASP.net WebAPI client (managed by us) built on .net framework 4.6.2, and the integration requires some configuration changes as we have gone through the forum. I have two questions regarding support of .net framework 4.6.x clients integrating with ID Server 5 or above :
With ID server v5 (on .net core), when a client built on .Net Framework 4.6.x tries to integrate with it, it requires changes on the ID server configuration to accept jwt instead of at+jwt (Reference: https://github.com/IdentityServer/IdentityServer4/issues/5081, https://github.com/IdentityServer/IdentityServer4/issues/3705, https://github.com/IdentityServer/IdentityServer4/issues/4188 ). It requires changes on the ID server instead of the client. Would this impact the integration of future clients with the ID server built on .net core. Please advise from a compatibility & support perspective for long term (The ID server is being managed by another entity and requesting changes on it would require approvals if this configuration is not recommended). Is it fine to change the configuration on ID server side to accept the jwt token instead of at+jwt ? Do you see any security or compatibility issues with this change on the ID server side. The changes that we are expecting to make it work are mentioned here.
Also, please advise if the Identity Server (on .net core) cannot change this setting for some reason (due to approvals not being granted or the ID server team is skeptical about this change on the server), how can clients built on .net framework 4.6 (or any client older than .net core) integrate with ID server? Should they call the userinfo endpoint of ID server from the CustomAuthorize attribute for each authorized API call? Is this approach recommended and will have no issues with security & performance going forward? Or is there any other recommended approach as well that can be looked into (Assuming client cannot upgrade to .net core).
@brockallen @leastprivilege