与外部提供商一起创建用于身份验证的安全服务
我想获得一些有关如何处理身份验证以使我的 Restful 服务能够支持的指导几个不同的场景，看到包含的图片吗？ 我已经考虑这个问题几个星期了，但没有找到所有情况的解决方案，即使我会做出权衡，我也会遇到问题
如果我们跳过移动应用程序和 Curl 的使用，无需向公众公开服务，并且可以对服务器到服务器的通信使用基本身份验证。但是我们仍然需要在“仅限忍者的网站”上承担一些责任，以将（openid 身份验证的用户）作为 http 标头的一部分传递？
在这种情况下，我们使用 Google 应用程序来管理同事的凭据，如果可以避免的话，我不喜欢在服务中管理另一个用户名/密码的想法。
是否有任何可持续的解决方案可以实现我的梦想，以便我可以为客户端构建出色的功能并实现一个严格的 API 来管理特定用户对不同资源的授权？
另一种可能的解决方案可能是将服务与 openid 提供商集成，但是这样我在从“仅限忍者的网站”传递用户时会遇到问题
I would like to have some guidance regarding how to handle authentication for my restful service to be able to support a couple of different scenarios, see included image?
I've been thinking about this problem for a couple of week without finding a solution for all of the cases and even if I'll make trade offs I'll be running into problems
If we skip the Mobile application and the use of Curl, there's no need to expose the service to the public and it would be possible to use basic authentication for the server to server communication. But we'll still need to put some responsibility at the "Web site for ninjas only" to pass the (openid authenticated user) as part for the http header?
In this case we're using Google apps to manage credentials for our co-workers and I don't like the idea to manage another username/password within the service if it's possible to avoid.
Is there any sustainable solution for my dreams, so that I can build awesome features for the client and implement a tight api that manages the authorization for different resources for a specific user?
Another possible to solution might be to integrate the service with the openid provider, but then I'll have problem with passing the user from "Web site for ninjas only"
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论