处理WebAPI时的身份验证授权问题

Question

我正在重新开发一个应用程序作为Web应用程序（“之前的”迭代在VB6中）以在 azure 上运行。一个要求是我们仅使用facebook / google身份验证（OAuth 2.0）。另一个业务要求导致我将项目分解为以下模式：

• 1 WebAPI 2.0项目
• 1控制器项目
• 1用于数据访问（典型图层模式）
• N MVC 5前端项目

这个想法是MVC项目只会通过javascript / json使用WebAPI！ N MVC项目将仅包含页面的GET实现。没有模型或其他动作（例如发布）。换句话说， MVC项目与其他项目完全断开连接，并且应该没有任何情报！

这是选择的方式，因为（讨厌的客户和时间限制） 无论如何，你可以注意到“核心”（WebAPI +控制器+ DA）是共享的。核心实际上是一种多租户服务。 （但请记住断开连接的方面！）

我的问题是：如何处理授权？什么/如何处理MVC项目和WebAPI之间的声明的传递？我迷失在这里。经过一番思考，我得出结论，我需要让WebAPI项目在这里充当代理，例如：

• 随机用户登陆www.myClientWebsite.com/Register
• 选择登录提供商
• MVC项目重定向用户信令facebook以返回www.myWebAPI.com/Register
• 我拦截了声明并将用户重定向到原始www.myClientWebsite.com/LoginComplete或其他内容......

我弄错了吗？

Answer 1

在此方案中，您必须使用OAuth 2进行身份验证和授权。是的，您应该在MVC级别进行身份验证，然后使用令牌来保持安全性，以便进行其他调用。

这里你的MVC应用程序应该从像谷歌这样的身份提供者那里获得一个Bearer令牌，然后将其隐藏在表单上的某个位置。然后，对于您对web api进行的每个jquery请求，您必须在请求中发送此承载令牌。

<强> [更新] 这被认为是一种黑客攻击，我不鼓励它。这只适用于两个系统都在同一个域中的情况。 的 [\更新]

如果MVC和Web API都位于不同的域上，那么您可以考虑使用Azure ACS服务标识来构建域之间的信任。然后在请求的有效负载中传递用户声明的承载令牌。

<强> [更新] 这是处理此问题的更好方法，但必须伴随正确的令牌撤销和https安全性。 的 [\更新]