我的公司正在使用MVC 4中的新Web API / SPA功能将其电子商务网站重新编写为单页面应用程序。我们不确定如何处理身份验证最佳方法。
具体问题：
我们如何同时处理加密和非加密通信？显然，我们需要在登录、帐户和结帐AJAX中使用HTTPS，但我们想在浏览目录时使用HTTP，以避免昂贵的SSL握手会减慢整个站点速度。这对于SPA来说是否可能，或者我们被迫全部使用HTTPS？
我们应该使用什么样的身份验证？首先，我们的网站将从Web浏览器访问，因此Cookie可能是可以的。但是未来，我们可能需要制作自定义的iPhone应用程序。Basic Authentication、OpenId或OAUTH哪种更可取？如果是，为什么？
提前致谢
您不必只使用一个协议。使用spa时，您可以选择在任何给定时间使用http或https来使用ajax进行通信。当您发送诸如人名、出生日期或登录凭据等敏感信息时，建议始终使用https。
一旦用户通过https登录到您的网站，您的服务器就可以为该用户设置一个表单身份验证cookie。此cookie应为加密值，将其会话与服务器绑定。但请注意，如果您网站的其他部分正在使用http，则有可能将此cookie以纯文本传递。即使cookie的内容可以使用您选择的加密算法进行加密，但恶意人员仍然可以窃取此cookie并劫持用户会话。
如果他们只允许浏览网站和创建购物车，这可能对您来说并不重要。一旦用户准备结帐，则应重新通过https对用户进行身份验证，以确保他们不是恶意用户。亚马逊就是这样做的。
嗯，这完全取决于您希望网站拥有哪些功能。
OAuth 用于暴露Web服务，允许其他站点使用委托访问进行调用。这意味着，如果您有一个用户希望另一个站点（站点x）能够访问其个人资料的功能。站点x可以将用户重定向到您网站上的oauth端点，该端点将对用户进行身份验证。您的oauth端点将询问用户是否同意与站点x共享某些功能，如果用户同意，则生成一个令牌。用户将此令牌传递给站点x，站点x将在服务器之间调用您的站点。站点x将在调用中呈现令牌，因此对您的服务的调用将是委派访问调用。OAuth是一种向其他站点提供委托访问权限的方法。希望我能表达清楚...我并不总是擅长这样做。
OpenID不是处理身份验证的一种非常安全的方式，它更像是一种方便的方式，使用户无需在您的站点上注册帐户。因为OpenID是完全开放的，所以您正在信任另一个提供程序来验证您的用户。如果第三方提供者的用户存储被攻击，则您的用户也会受到影响。这是一个代金券系统的示例，您基本上在说如果你有一个OpenID提供商为你背书，我将相信你是谁。
另一种解决方案是WS-Federation。如果您有多个站点并且想要一个受信任的认证提供程序，则可以使用WS-Federation。此认证提供程序可以是您自己的，并且基本上所有网站都会说，如果您要访问我的站点，则必须先通过我的认证提供程序进行身份验证。此认证提供程序可以存在于一个单独的域中，并且可以选择任何身份验证机制。您正在信任此auth提供程序将尽最大努力管理您的用户帐户。
但是，如果您只想在您的站点上进行身份验证而且没有多个站点，则WS-Federation可能过于繁琐。在这种情况下，我建议仅使用Forms Authentication，这应该很容易做到。有很多如何做到这一点的例子，Microsoft提供了许多解决方案。您应该考虑创建自定义成员资格提供程序。
一旦用户已经在您的站点上进行了身份验证，您应该创建一个forms authentication cookie。此cookie将用户与其在服务器上的会话相关联。这适用于上述所有情况。MVC 4也支持上述所有情况。
谢谢，并且如果我没有表达清楚，可以随时问更多问题。
**编辑12/1/2017**
几年后回到这个问题，我学到了一点关于REST API不应该依赖cookie的知识。你不想为你的web应用程序创建会话，因为这使得你的应用程序更难扩展。所以，如果你需要身份验证，那么请使用带有某种形式的身份验证（基本，摘要，令牌等）的HTTPS。因此，你的SPA客户端应用将在每个http请求上设置授权头，然后你的Web服务器应用程序将重新验证每个请求。欢迎提供反馈。
我刚刚开始使用webapi，所以不要把我的回答当作权威。虽然我并不是一个安全专家，但我应该成为一个。我遇到了和你一样的问题，并且发现，就mvc webapi而言，确实没有权威的答案，正如你所发现的那样。看看其他webapi规范可能会给你一些灵感。
最简单的方法当然是使用SSL。这样可以在头部以明文形式发送凭据，而不会破坏REST。
我的api将始终使用SSL，但我仍然想要做一层双重保护。因此，我在所有请求中都在查询字符串中发送了一个加密的密钥。这基本上与非api asp站点的无cookie身份验证方式类似，但是mvc对其不起作用，所以我自己开发了解决方案。
在移动网站上，用户登录后，将被重定向到包含加密密钥的js的应用程序中。因此，他最初将获得基于Cookie的站点身份验证，并负责保护它，保存密码等。
另一个api消费者将从尚未制作的开发站点获取一个更永久的“秘密”，并使用该秘密来获取一个密钥。
通常MVC身份验证是无状态的，这意味着票证从未在服务器端失效。如果您控制客户端，则可以忽略使cookie失效的请求，如果服务器将您注销，则可以继续重复使用该票证。最终，您可能希望在服务器端跟踪您的票证，但它不是无状态的，怀疑它是否符合RESTful，并因此可扩展性受到影响。但是身份验证非常重要，所以...