问题
比方说，一个组织要求其所有消费者（非员工）用户都有一个单一的用户身份。该组织规模庞大，有许多业务部门运营自己的面向消费者的应用程序，但所有这些应用程序都需要使用单个IDP的用户。
每个业务单元必须能够使用IDP控制自己的应用程序配置，并且不能控制任何其他BU的应用程序设置。
所有消费者身份都是作为组织用户配置过程的一部分创建的，以验证此人是谁。不会进行自我注册。
选项1
我的第一个想法是有单独的身份服务器，每个业务单元一个。这至少提供了配置分离。然后只为消费者用户提供一个单一的组织IDP。
每个业务部门特定的IDP都将支持组织IDP的登录，可以从业务部门IDP登录屏幕中进行选择，也可以在业务部门特定应用程序要求时立即重定向到组织IDP。
这是一种多租赁，尽管不是在一个单一的服务中。这意味着每个BU都管理其用户身份和应用程序配置，并允许通过单一组织身份（加上本地BU IDP帐户）登录。此外，管理员（一些员工）用户可以通过本地BU帐户或公司AAD身份登录（如果配置的话）。
选项2
拥有一个单一的组织标识服务器，并提供一个配置api/ui来支持客户端和范围数据的分区。这意味着每个BU将仅限于其应用程序身份配置数据，但将允许所有用户使用所有应用程序，而无需拥有许多本地帐户（每个BU IDP中有一个）。
每个应用程序都必须有某种命名约定，以使作用域与另一个BU应用程序中使用的作用域不冲突。类似_mywebapi的东西。
我的问题是，选项1是否应该是架构选择，而不是选项2，在选项2中，许多业务部门希望控制自己的基于令牌的应用程序，但希望使用单个用户身份？或者还有其他选择吗？
您可以将两者结合起来。您可以有一个中央令牌服务来实现SSO，它所做的一切都会为用户向所有业务单元发布一个唯一的id。然后，业务单元有自己的令牌服务，允许他们控制应用程序和api的访问和配置。
要将两个令牌服务连接在一起，您需要将业务单元令牌服务联合到中央令牌服务。