Jor*_*den 15 authentication asp.net-web-api single-page-application asp.net-spa
我的公司正在使用MVC 4中的新Web API/SPA功能将其电子商务站点重新编写为单页面应用程序.我们不确定如何处理身份验证的最佳方法.
具体问题:
我们如何处理加密和非加密通信？显然,我们需要使用HTTPS进行登录,帐户和结账AJAX,但我们希望使用HTTP浏览目录,以避免昂贵的SSL握手,这会降低整个网站的速度.这对于SPA来说是否可能,或者我们是否仍然坚持使用HTTPS？
我们应该使用哪种身份验证？主要是我们的网站将通过网络浏览器访问,因此cookie可能没问题.但在未来,我们可能想要制作一个自定义的iPhone应用程序.基本身份验证,OpenId或OAUTH更受欢迎吗？如果是这样,为什么？
提前致谢
Eva*_*sen 10
你没有坚持一个协议.使用spa,您可以使用ajax通过http或https进行通信,无论您在任何给定时间选择哪一个.我会在您发送敏感信息时使用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就是如此.此身份验证提供程序可以是您的,并且基本上所有站点都说如果您想要访问我的站点,那么您必须首先通过我的身份验证提供程序进行身份验证.此身份验证提供程序可以位于单独的域上,并可以选择其选择的任何身份验证机制.您相信此身份验证提供商将尽最大努力管理您的用户帐户.
如果您只想在您的站点上进行身份验证并且没有多个站点,那么WS-Federation可能会过度使用.在这种情况下,我只是建议进行表单身份验证,这应该很简单.有很多关于如何做到这一点的例子,微软为如何做到这一点提供了许多解决方案.您应该考虑创建自定义成员资格提供程序.
用户通过您的站点进行身份验证后,您应该创建一个表单身份验证cookie.此cookie将用户绑定到服务器上的会话.这适用于上面列出的所有方案.MVC 4也支持上面列出的所有场景.
谢谢,如果我不够清楚,可以随意提出更多问题.
**编辑12/1/2017**多年后回到这个问题我已经了解到依赖基于REST的API的cookie并不是一个好主意.您不希望在Web应用程序上创建会话,因为它会使您的应用程序难以扩展.因此,如果您需要身份验证,请使用HTTPS以某种形式的身份验证(BASIC,DIGEST,Token Based等).因此,您的SPA客户端应用程序将在每个http请求上设置Authorization标头,然后您的Web服务器应用程序将重新验证每个请求.
Mar*_*tin -1
我自己刚刚开始使用 webapi，所以不要认为我的答案具有权威性。我不是安全专家，尽管我应该是。我遇到了与您相同的问题，并发现，正如您所做的那样，无论如何，在 mvc webapi 中都没有权威的答案。查看其他 webapi 规范可能会给您一些灵感。
我遇到的最简单的方法当然是使用 SSL。这样您就可以在标头中以明文形式发送凭据。不打扰休息。
我的 api 将一直使用 SSL，但无论如何我想加倍。因此，我在查询字符串中为我的所有请求发送加密密钥。几乎与非 api asp 站点的 cookieless 身份验证工作方式相同，但 mvc 无法使用它，因此我推出了自己的解决方案。
在移动网站上，用户将使用编码到 js 中的加密密钥登录并重定向到应用程序。因此，他最初将为该网站提供基于 cookie 的身份验证，并负责其保护、密码保存等。
另一个 API 消费者将从尚未创建的开发站点获得更永久的“秘密”，并使用它来检查密钥。
通常，mvc 身份验证是无状态的，这意味着票证永远不会在服务器端失效。如果您控制客户端，则在服务器将您注销时，您可以忽略无效的 cookie 请求，并继续重复使用票证。最终，您可能想要跟踪您的票证服务器端，但它不是无状态的，怀疑它是否完整，结果可扩展性受到打击。但身份验证非常重要，所以......