使用 OAuth 保护使用 SSO 的服务
这是一个概念性的挑战，我正在努力解决这个问题。假设我有一个 SSO（单点登录）服务和两个使用它的独立 Web 服务。假设 SSO 登录是通过 OAuth 进行的，就像使用 Facebook 登录一样。 （如果我错了，请纠正我，他们不仅仅是为相关网站请求 OAuth 访问令牌。）
那么问题是，这两个 Web 服务应该如何向第三方公开自己的 API？鉴于我们已经喝醉了 OAuth kool 援助，第三方应该被视为 OAuth 消费者并且他们应该请求用户批准他们的访问令牌似乎是合乎逻辑的。接受这个问题：Web 服务是否应该自己处理所有这些 OAuth 内容，让第三方向他们注册为 OAuth 使用者，并且仅使用 SSO 来登录用户？或者，Web 服务是否应该将所有责任交给 SSO 服务？对于签名请求，Web 服务将通过 SSO 的 API 检查访问令牌的有效性，然后正常处理。
我看到这两种方法都有优点和缺点。一方面，第一个选项对 SSO 的要求较少，并且每个 Web 服务都可以按照自己的方式处理其 API 的授权。另一方面，让 SSO 处理事务意味着第三方可以获得在所有服务中有效的访问令牌，就像用户可以在所有服务中登录一样。
这可以实现更好的用户体验，否则第三方可能不得不不断地请求用户授权，因为它需要使用系统的不同Web服务，尽管不同Web服务之间的分隔对用户来说是不可见的。当然，那么要么 SSO 需要某种共享权限规则，要么每个 Web 服务仍需要强制执行自己的规则。此外，当要求用户授权第三方服务时，SSO 可能必须从 Web 服务中获取某种文本或 HTML 来显示。
有什么建议吗？是否有任何现有的、公开记录的系统可以很好地做到这一点？我是不是把整个事情搞得太复杂了？
This is a conceptual challenge that I'm trying to wrap my mind around. Let's say I have an SSO (single sign on) service and two separate web services that use it. Let's say that the SSO login happens via OAuth, just like Login with Facebook. (Correct me if I'm wrong that they're not just requesting an OAuth access token for the site in question.)
The question is then, how should the two web services expose their own APIs to third parties? Given that we've drunken the OAuth kool aid, it seems logical that the third parties should be considered OAuth consumers and they should request that the user approves an access token for them. Accepting that the question is, should the the web services handle all this OAuth stuff themselves, having the third parties register as OAuth consumers with them and only using the SSO to login the user? Or, should the web services hand all responsibility off to the SSO service? For signed requests, the web service would check the validity of the access token via the SSO's API and then process it as normal.
I see pluses and minuses to both approaches. On one hand, the first option places fewer demands on the SSO and each web service can handle the authorization for their APIs their own way. On the other hand, having the SSO handle things means that the third parties can get access tokens that are valid across all the services, just like how users can login across all of them.
This can enable a better user experience, as otherwise the third party might have to keep asking the user for authorization as it needs to use different web services of the system, despite the separation between the different web services being invisible to the user. Of course, then either the SSO needs to have some sort of shared permission rules or each web service will still need to enforce its own rules. Also, the SSO would probably have to take some sort of text or HTML from the web services to display when asking the user to authorize the third party service.
Any suggestions? Are there any existing, publicly documented systems that do this well? Am I just over-complicating the whole thing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论