We need to integrate SSO to allow already-logged-in users of our system to login to a third-party web hosting provider. The provider requires OIDC for SSO, but they expect all our users to already have an identity provider (IdP). We already support SSO into our app for Google, Microsoft, and Okta users, so we are not entirely ignorant of OIDC. But the direction we have implemented is the opposite, Third-Party IdP --> Us, not Idp (Us) --> Third-Party.
As our system is 20+ years old, the majority of our user base is in our own custom credential store designed pre-OIDC. We are not an IdP. Also, we support only .NET Framework 4.8.1. (i.e. not Core/5+). What would be the easiest way to proceed? The third party requires:
I saw this post from 2012, and it's almost exactly the same situation as ours, but the DotNetOpenAuth repository has been archived since 2019. There is also the IdentityServer project, but IdentityServer3 seems to be the most recent version that still supports .NET Framework (not Core), and it hasn't been updated since 2018.
Can anyone suggest a currently-maintained .NET Framework (not Core/5+) library that can implement an OIDC IdP?
I always aim to explain the architecture in term of thinking backwards from APIs. But let me know if you think I've misunderstood anything.
AUTHORIZATION SERVER
The preferred architecture is for your apps and APIs to only interact with an AS, for the simplest code and best capabilities. The AS issues access tokens whose scopes and claims you can lock down, to best protect your business data.
Also, users can potentially sign into your client applications in many ways, eg Google IDP, Microsoft IDP, WebAuthn, other organization, depending on how you configure the AS.
FEDERATED LOGINS
A federated login flow across organizations, where all parties use OIDC, works like this:
Client runs a code flow to redirect to AS1
AS1 will redirect to AS2 using another code flow. From AS2's viewpoint, AS1 is just another client. AS2 can use all of its existing login methods, or alternatively act as a simple IDP.
Client is issued tokens by AS1 - the one that protects its business data.
SUMMARY
In your case you seem to lack the authorization server role, which is a prerequisite to do this type of integration in the best way.
If your apps and APIs used one, and it supported the correct behaviours, your AS would implement the AS2 role above for the use case you describe. An AS should be able to integrate with existing user and credential stores.
To integrate an IDP or AS, you would need to look into those that support OIDC and also integration with existing data sources, eg docker based. A solution is not limited to .NET, since you will just use its endpoints. It is against SO guidelines to recommend providers though.