首页 文章

SPA身份验证和会话管理的最佳实践

提问于
浏览 次
243

使用Angular，Ember，React等框架构建SPA风格的应用程序时，人们认为什么是身份验证和会话管理的最佳实践？我可以想到几种方法来考虑解决问题 .

  • 假设API和UI具有相同的原始域，则与使用常规Web应用程序的身份验证没有区别 .

这可能涉及具有会话cookie，服务器端会话存储以及可能的一些会话API endpoints ，经过身份验证的Web UI可以点击以获取当前用户信息以帮助个性化或甚至可能确定客户端上的角色/能力 . 当然，服务器仍然会实施保护数据访问的规则，UI只会使用这些信息来定制体验 .

  • 将其视为使用公共API的任何第三方客户端，并使用某种类似于OAuth的令牌系统进行身份验证 . 客户端UI将使用此令牌机制来验证对服务器API发出的每个请求 .

我在这里并不是一位专家，但对于绝大多数情况来说，＃1似乎已经足够了，但我真的很想听到一些更有经验的意见 .

security angularjs authentication ember.js single-page-application

3 回答

  • 406

    这个问题已经以稍微不同的形式进行了详细讨论，在这里：

    RESTful Authentication

    但这是从服务器端解决的 . 让我们从客户端看这个 . 然而，在我们这样做之前，有一个重要的前奏：

    Javascript加密是无望的

    Matasano关于此的文章很有名，但其中包含的课程非常重要：

    http://www.matasano.com/articles/javascript-cryptography/

    总结一下：

    • 中间人攻击可以用 <script> function hash_algorithm(password){ lol_nope_send_it_to_me_instead(password); }</script> 轻松替换你的加密代码

    • 对于通过非SSL连接为任何资源提供服务的页面，中间人攻击是微不足道的 .

    • 一旦你拥有了SSL，你就会使用真正的加密技术 .

    并添加我自己的推论：

    • 成功的XSS攻击可能导致攻击者使用SSL在您的客户端上执行代码's browser, even if you'，即使您使用了've got every hatch battened down, your browser crypto can still fail if your attacker finds a way to execute any javascript code on someone else'浏览器 .

    如果您打算使用JavaScript客户端，这会使许多RESTful身份验证方案变得不可能或愚蠢 . 我们看看吧！

    HTTP Basic Auth

    首先，HTTP Basic Auth . 最简单的方案：只需为每个请求传递一个名称和密码 .

    当然，这绝对需要SSL，因为您在每次请求时都会传递Base64（可逆）编码的名称和密码 . 任何在线听的人都可以简单地提取用户名和密码 . 大多数“Basic Auth都是不安全的”论据来自“Basic Auth over HTTP”，这是一个非常糟糕的主意 .

    浏览器提供了烘焙的HTTP Basic Auth支持，但它很丑陋，您可能不应该将它用于您的应用程序 . 不过，另一种方法是在JavaScript中隐藏用户名和密码 .

    这是最RESTful的解决方案 . 服务器不需要任何状态知识，并且验证与用户的每个单独交互 . 一些REST爱好者（主要是稻草人）坚持认为，维持任何形式的状态都是异端邪说，如果你想到任何其他认证方法，它会在嘴里发泡 . 这种标准兼容性有理论上的好处 - 它由开箱即用的Apache支持 - 如果你的心愿，你可以将你的对象存储在受.htaccess文件保护的文件夹中！

    problem ？您正在客户端缓存用户名和密码 . 这给了evil.ru一个更好的破解 - 即使是最基本的XSS漏洞也可能导致客户端将他的用户名和密码发送到恶意服务器 . 您可以尝试通过散列和腌制密码来减轻这种风险，但请记住： JavaScript Crypto is Hopeless . 你可以通过将它留给浏览器的Basic Auth支持来减轻这种风险，但是......如上所述，丑陋如罪 .

    HTTP摘要验证

    Is Digest authentication possible with jQuery?

    更多"secure" auth，这是一个请求/响应哈希挑战 . 除了 JavaScript Crypto is Hopeless 之外，它只适用于SSL，您仍然需要在客户端缓存用户名和密码，使其比HTTP Basic Auth更复杂，但不再安全 .

    使用其他签名参数进行身份验证 .

    另一个更“安全”的身份验证，你用nonce和计时数据加密你的参数（以防止重复和定时攻击）并发送 . 其中一个最好的例子是OAuth 1.0协议，据我所知，这是一种在REST服务器上实现身份验证的非常好的方法 .

    http://tools.ietf.org/html/rfc5849

    哦，但是没有任何适用于JavaScript的OAuth 1.0客户端 . 为什么？

    JavaScript Crypto is Hopeless ，记住 . JavaScript可以在本地使用't participate in OAuth 1.0 without SSL, and you still have to store the client'用户名和密码 - 这与Digest Auth属于同一类别 - 它's more complicated than HTTP Basic Auth but it'不再安全 .

    令牌

    用户发送用户名和密码，并在交换中获取可用于验证请求的令牌 .

    这是比HTTP Basic Auth更安全，因为只要用户名/密码事务完成，您就可以丢弃敏感数据 . 它也不那么RESTful，因为令牌构成“状态”并使服务器实现更复杂 .

    SSL仍然

    但是，你仍然需要发送初始用户名和密码才能获得令牌 . 敏感信息仍然触及您可妥协的JavaScript .

    为了保护用户的凭据，您仍然需要阻止攻击者使用JavaScript，并且仍然需要通过网络发送用户名和密码 . SSL必需 .

    令牌到期

    它非常确定允许使用此令牌的唯一IP地址是 XXX.XXX.XXX.XXX “ . 许多这些策略都是非常好的想法 .

    Firesheeping

    但是，使用不带SSL的令牌仍然容易受到名为'sidejacking'的攻击：http://codebutler.github.io/firesheep/

    攻击者不会获得您的用户凭据，但他们仍然可以伪装成您的用户，这可能非常糟糕 .

    tl; dr：通过电线发送未加密的令牌意味着攻击者可以轻易地 grab 这些令牌并伪装成您的用户 . FireSheep是一个让这很容易的程序 .

    一个独立，更安全的区域

    您运行的应用程序越大，就越难以确保它们无法注入一些代码来改变您处理敏感数据的方式 . 你绝对相信你的CDN吗？你的广告商？你自己的代码库？

    信用卡详细信息的常见内容以及用户名和密码不太常见 - 一些实施者将“敏感数据输入”保留在与其应用程序其余部分不同的页面上，该页面可以尽可能严格控制和锁定，最好是一个很难用户网络钓鱼 .

    Cookie（只是表示令牌）

    将身份验证令牌放在cookie中是可能的（也是常见的） . 这不会改变使用令牌的auth的任何属性，这更方便 . 所有以前的论点仍然适用 .

    会话（仍然只是表示令牌）

    会话身份验证只是令牌身份验证，但有一些差异使它看起来有点不同：

    • 用户以未经身份验证的令牌开头 .

    • 后端维护一个绑定到用户令牌的'state'对象 .

    • 令牌在cookie中提供 .

    • 应用程序环境将详细信息从您身上抽象出来 .

    除此之外，它与Token Auth没有什么不同，真的 .

    这远远超出了RESTful实现 - 使用状态对象，您将继续沿着有状态服务器上的普通OL的路径前进 .

    OAuth 2.0

    OAuth 2.0着眼于“软件A如何让软件B访问用户X的数据，而软件B无法访问用户X的登录凭据” .

    实现只是用户获取令牌的标准方式，然后是第三方服务“是的，这个用户和这个令牌匹配，你现在可以从我们那里获得他们的一些数据 . ”

    但是，从根本上说，OAuth 2.0只是一种令牌协议 . 它展示了与其他令牌协议相同的属性 - 您仍需要SSL来保护这些令牌 - 它只会更改这些令牌的生成方式 .

    OAuth 2.0有两种方式可以帮助您：

    • 向他人提供身份验证/信息

    • 从其他人那里获取身份验证/信息

    但是当它归结为它时，你只是......使用令牌 .

    回到你的问题

    所以，你问的问题是“我应该将我的令牌存储在cookie中并让我的环境的自动会话管理处理细节，还是应该将我的令牌存储在Javascript中并自己处理这些细节？”

    答案是：做任何让你开心的事 .

    然而，关于自动会话管理的事情是，幕后为你做了很多魔术 . 通常，自己控制这些细节会更好 .

    我21岁，所以SSL是肯定的

    另一个答案是：使用https进行所有操作，或者盗贼将窃取用户的密码和令牌 .

    回复于
  • 47

    您可以使用JWT（JSON Web令牌）和SSL / HTTPS提高身份验证过程的安全性 .

    基本身份验证/会话ID可以通过以下方式被盗：

    • MITM攻击（Man-In-The-Middle） - 没有SSL / HTTPS

    • 入侵者获得对用户计算机的访问权限

    • XSS

    通过使用JWT，您可以将're encrypting the user'的身份验证详细信息存储在客户端中，并将其与每个请求一起发送到API，其中服务器/ API验证令牌 . 没有私钥（服务器/ API秘密存储） Read update ，它无法解密/读取 .

    The new (more secure) flow would be:

    登录

    • 用户登录并向API发送登录凭据（通过SSL / HTTPS）

    • API接收登录凭据

    • 如果有效：

    • 在数据库中注册新会话 Read update

    • 使用私钥加密JWT中的用户ID，会话ID，IP地址，时间戳等 .

    • API将JWT令牌发送回客户端（通过SSL / HTTPS）

    • 客户端收到JWT令牌并存储在localStorage / cookie中

    每个API请求

    • 用户使用HTTP标头中存储的JWT令牌向API发送HTTP请求（通过SSL / HTTPS）

    • API读取HTTP标头并使用其私钥解密JWT标记

    • API验证JWT令牌，将HTTP请求中的IP地址与JWT令牌中的IP地址匹配，并检查会话是否已过期

    • 如果有效：

    • 返回包含所请求内容的回复

    • 如果无效：

    • 抛出异常（403/401）

    • 标记系统中的入侵

    • 向用户发送警告电子邮件 .

    Updated 30.07.15:

    实际上可以在没有私钥（秘密）的情况下读取JWT有效载荷/声明，并且对这些虚假陈述抱歉.767355_抱歉 . 然而，他们似乎正在努力JWE standard (JSON Web Encryption) .

    我通过在JWT中存储声明（userID，exp）来实现这一点，使用私钥（秘密）对其进行签名，API /后端仅知道并将其存储为客户端上的安全HttpOnly cookie . 这样它就无法通过XSS读取而无法操作，否则JWT会失败签名验证 . 此外，通过使用安全的HttpOnly cookie，您可以确保cookie仅通过HTTP请求（脚本无法访问）发送，并且仅通过安全连接（HTTPS）发送 .

    Updated 17.07.16:

    JWT本质上是无国籍的 . 这意味着它们会使自己失效/失效 . 通过在令牌的声明中添加SessionID，您将其设置为有状态，因为它的有效性现在不仅取决于签名验证和到期日期，它还取决于服务器上的会话状态 . 然而，好处是你可以轻松地使令牌/会话无效，而无法使用无状态JWT .

    回复于
  • 7

    我会去第二个，令牌系统 .

    你知道ember-auth或ember-simple-auth吗？它们都使用基于令牌的系统，如ember-simple-auth状态：

    一个轻量级且不显眼的库，用于在Ember.js应用程序中实现基于令牌的身份验证 . http://ember-simple-auth.simplabs.com

    他们有会话管理，也很容易插入现有项目 .

    还有一个Ember App Kit示例版本的ember-simple-auth：Working example of ember-app-kit using ember-simple-auth for OAuth2 authentication.

    回复于

相关问题