基于现有OAUTH授权API实现Azure多Web应用SSO方案咨询

嘿，我来帮你梳理下这个跨Azure Web App的SSO实现方案——首先明确说：不需要Azure虚拟机，至于Azure Active Directory（AAD），不是必须的，但用它能大幅简化流程；当然你也可以基于现有的OAuth授权服务器来实现SSO，下面分两种情况给你拆解：

要让两个MVC客户端共享登录状态，核心是让它们和授权服务器共享身份验证会话，具体要做这几件事：

• 统一域名配置：把你的两个MVC客户端（webapp1、webapp2）和WEB API授权服务器部署在同一个根域名下，比如webapp1.yourdomain.com、webapp2.yourdomain.com、auth.yourdomain.com。然后在授权服务器的Cookie配置里，把Cookie的域设置为.yourdomain.com（注意前面的点），这样两个客户端都能读取授权服务器下发的会话Cookie。
• 客户端注册与回调配置：在WEB API的数据库客户端配置里，添加第二个MVC客户端的ClientId、ClientSecret，并设置正确的回调URL（比如https://webapp2.yourdomain.com/signin-oauth）。同时在webapp2的MVC配置中，指定对应的OAuth参数，指向你的WEB API授权服务器地址。
• 分布式会话存储：因为Azure Web App是多实例部署，默认的内存会话无法跨实例共享。所以要在WEB API授权服务器中配置分布式会话存储，比如Azure Redis Cache或者Azure SQL Server，确保用户登录后的会话数据能在所有服务器实例间共享，这样webapp2跳转过来时，授权服务器能识别到已登录状态。
• 测试验证：用户在webapp1登录后，访问webapp2时，会自动跳转到授权服务器，此时授权服务器检查到已有有效会话，会直接返回身份令牌给webapp2，无需再次登录，实现SSO。

如果不想自己维护授权服务器的SSO逻辑，完全可以用Azure AD作为统一身份提供商，这会省掉很多会话共享、Cookie配置的麻烦：

• 应用注册：在Azure AD中分别为webapp1、webapp2和WEB API创建应用注册，配置好各自的重定向URL和API权限。
• 客户端配置：修改两个MVC客户端的身份验证逻辑，从原来的自建WEB API授权服务器切换到Azure AD，使用OpenID Connect协议实现登录。
• API保护：把WEB API配置为受Azure AD保护的资源，客户端通过Azure AD获取的令牌来访问API。
• 这种方案下，Azure AD会自动处理跨应用的SSO——用户在任意一个客户端登录后，其他同租户的应用都会识别到已登录状态，完全不需要自己处理会话和Cookie的细节，而且全程基于Azure PaaS服务，不需要虚拟机。

• 不需要Azure虚拟机，两种方案都基于Azure Web App或其他PaaS服务就能实现。
• 如果想保留现有自建授权服务器，按方案一配置即可；如果想简化维护，方案二的Azure AD是更省心的选择。

内容的提问来源于stack exchange，提问作者Bala P