我的公司正在使用 MVC 4 中的新 Web API / SPA 功能将其电子商务站点重写为单页应用程序。我们不确定如何处理身份验证的最佳方法。
具体问题：
我们如何处理加密和非加密通信？显然，我们需要为登录、帐户和结帐 AJAX 使用 HTTPS，但我们希望使用 HTTP 来浏览目录，以避免昂贵的 SSL 握手会减慢整个站点的速度。这对于 SPA 来说是否可行，或者我们是否对所有事情都坚持使用 HTTPS？
我们应该使用什么样的身份验证？主要是通过网络浏览器访问我们的网站，因此 cookie 可能没问题。但在未来，我们可能想要制作一个定制的 iPhone 应用程序。基本身份验证、OpenId 还是 OAUTH 更可取？如果是这样，为什么？
提前致谢
您不会拘泥于一种协议。使用 spa，您可以使用 ajax 通过 http 或 https 进行通信，无论您在任何给定时间选择哪一个。我会在您发送敏感信息（例如人名、生日或登录凭据）时使用 https。
一旦用户通过 https 登录到您的站点，您的服务器就可以为该用户设置表单身份验证 cookie。这个 cookie 应该是一个加密值，将他们的会话与服务器联系起来。您必须知道，如果您网站的其余部分使用 http，那么您就有此 cookie 以纯文本形式通过网络传递的风险。即使 cookie 的内容可以加密，但使用您选择的加密算法，恶意人员可以窃取此 cookie 并劫持您用户的会话。
如果只允许他们浏览网站并创建购物车，这对您来说可能没什么大不了的。一旦用户准备好结账，那么您应该通过 https 重新验证用户身份，作为一种双重检查，以确保他们不是恶意用户。亚马逊就是这样做的。
好吧，这完全取决于您希望您的网站具有哪些功能。
身份验证用于公开 Web 服务，您可以允许其他站点以委托访问权限调用这些服务。这意味着如果您的用户希望另一个站点（站点 x）能够访问您站点上的功能以获取其个人资料。站点 x 可以将用户重定向到您站点上的 oauth 端点，该端点将对用户进行身份验证。您的 oauth 端点将询问用户是否可以与站点 x 共享某些功能，以及用户是否同意将生成令牌。用户将此令牌传递给站点 x，其中站点 x 将对您的站点进行服务器到服务器的调用。站点 x 将在调用中显示令牌，因此对您的服务的调用将是委托访问调用。OAuth 是一种配置其他站点以对您的服务进行委派访问的方法。我希望我能够清楚地解释这一点。我并不总是擅长这一点。
OpenID不是一种非常安全的身份验证方式，它更加方便，因此用户不必为在您的站点注册帐户而烦恼。因为 OpenID 是完全开放的，所以您信任另一个提供商来验证您的用户。如果第三方提供商的用户存储受到威胁，那么您的用户也会受到威胁。这是凭证系统的一个示例，您基本上是在说我会相信您所说的，如果您可以让 OpenID 提供商为您担保的话。
另一种解决方案是WS-Federation。WS-Federation 是如果您有多个站点并且您希望拥有 1 个您信任的身份验证提供程序。该身份验证提供者可以是您的，基本上您的所有网站都说如果您想访问我的网站，那么您必须首先通过我的身份验证提供者进行身份验证。此身份验证提供程序可以存在于单独的域中，并且可以选择它选择的任何身份验证机制。您相信此身份验证提供商会尽最大努力管理您的用户帐户。
但是，如果您只想在您的站点上进行身份验证并且没有多个站点，则 WS-Federation 可能会有点过分。在这种情况下，我只建议进行表单身份验证，这应该很简单。有很多关于如何做到这一点的例子，微软为如何做到这一点提供了许多解决方案。您应该考虑创建自定义成员资格提供程序。
一旦用户通过您的站点的身份验证，您应该创建一个表单身份验证 cookie。此 cookie 将用户与他们在服务器上的会话联系起来。这适用于上面列出的所有场景。MVC 4 也支持上面列出的所有场景。
谢谢，如果我不够清楚，请随时提出更多问题。
** 编辑 2017 年 12 月 1 日 ** 多年后回到这个问题，我了解到依靠 cookie 来获取基于 REST 的 API 并不是一个好主意。您不想在 Web 应用程序上创建会话，因为这会使您的应用程序更难扩展。因此，如果您需要身份验证，请使用 HTTPS 和某种形式的身份验证（BASIC、DIGEST、基于令牌等）。因此，您的 SPA 客户端应用程序将在每个 http 请求上设置授权标头，然后您的 Web 服务器应用程序将重新验证每个请求。
使用 ASP.NET 基于表单的安全性的主要缺点是，它假定您在身份验证失败时需要一个 401 网页（在您进行 AJAX 调用时无用），并且它实际上是围绕执行重定向而设计的，这种重定向会破坏整体SPA 模式。你可以绕过它，但它不是为你使用它的目的而设计的。
该工具包可以提供 ASP.NET 作为表单模型的替代方案。还不知道成熟到什么程度……
欢迎反馈。
我自己刚开始使用 webapi，所以不要认为我的答案是权威的。尽管我应该是安全专家，但我不是安全专家。我遇到了和你一样的问题，发现和你一样，虽然没有权威的答案 - 无论如何在 mvc webapi 中。查看其他 webapi 规范可能会给您一些启发。
我遇到的最简单的方法当然是使用 SSL。这样您就可以在标题中以明文形式发送凭据。不破坏休息。
我的 api 将一直使用 SSL，但无论如何我想加倍。因此，我在查询字符串中为我的所有请求发送了一个加密密钥。无 cookie 身份验证的方式几乎与非 api asp 站点的工作方式相同，但 mvc 不能使用它，所以我推出了自己的解决方案。
在移动网站上，用户将使用编码到 js.js 中的加密密钥登录并被重定向到应用程序。因此，他最初将拥有该站点的基于 cookie 的身份验证，并负责其保护、密码保存等。
另一个 api 使用者将从尚未制作的开发站点获得更永久的“秘密”，并使用它来检查密钥。
通常 mvc 身份验证是无状态的，这意味着票证永远不会在服务器端失效。如果您控制客户端，则可以在服务器将您注销时忽略无效的 cookie 请求，并继续重用票证。最终，您可能想要跟踪您的票务服务器端，但它不是无状态的，怀疑它是否完全正常，因此可伸缩性受到了打击。但是身份验证非常重要，所以...