IdentityServer作为saas -体系结构问题

Question

我们使用IdentityServer为我们的几个应用程序提供SSO服务，并为不同的外部提供者提供插件。我们已经将ASP.NET标识应用于IdentityServer，但是我们没有本地用户，只有外部提供者。因此，IdentityServer作为一个SSO身份网关工作。每个客户都有自己的应用程序集和一个带有数据库的身份服务器应用程序。以及一个SPA应用程序，用于将GUI发送到IdentityServer/ASP.NET标识库。

如果我们稍微提高一下视线，那么saas身份提供商可以替代我们自己的中心身份提供商(维护IdentiyServer实际上不在我们的核心业务之外，应该被外包)。我的意思是，identity saas解决方案应该包含一个可配置的存储库，我们从IdentityServer和ASP.NET标识中将其识别为：

• ApiResources，ApiScopes
• 客户，ClientClaims，ClientCorsOrigins，ClientGrantTypes，ClientPostLogoutRedirectUris，ClientRedirectUris，ClientScopes，ClientSecrets
• IdentityResources，IdentityClaims
• EmailType
• 外部提供者配置，具体针对每个提供者，如AzureAD、OKTA、Facebook等。

为所有标识服务提供REST，并为所有管理提供GUI。

这似乎是一个基本的问题，但我认为很多公司都有自己的身份服务器，但它真的是核心业务吗？最好是在一个完全可配置的saas解决方案中订阅一个完全可配置的saas解决方案中的等效功能，并有一个通信点。

您有这种saas服务的经验吗？请举例说明。

Answer 1

许多托管服务提供了与IdentityServer类似的功能，其中一些服务是：

• Auth0
• 奥克塔

但是IdentityServer的优点是它是一个高度可配置的框架，允许您进行比基于云的定制更多的定制。