首先,“做的”：
>使用JWT为我的REST API [1] [2]授权用户
>将JWT存储在HTTPOnly / Secure Cookie中,构建CSRF保护.不要存储在HTML5本地存储中[3] [4] [5](实际上,这一点是有争议的,更容易保护免受XSS或CSRF？[6])
>验证JWT [7]的签名方法
现在我开始假设有一个SPA(用Angular构建)并使用HTML5 sessionStorage对于短命令令牌来说足够安全,但是有一点可以指出,XSS攻击可能发生在源自于“许多图书馆从CDN加载的其中之一.
对于我的具体用例,我不打算使用长期使用的令牌 – 在不使用10分钟后到期,但是我仍然在找出是否要按会话跟踪到期或使用刷新令牌 – StormPath推荐使用前者不再是无状态的),但是我相信使用JWT的大型玩家使用刷新令牌(Google使用它们,但指出您需要将它们存储在安全的长期存储中,这意味着HTML5本地存储再次成为问题).
我想这样做,所以我的用户不必重新登录,如果他们刷新页面(因此需要在客户端存储令牌).我也想在科尔多瓦的帮助下使用我的SPA作为“移动应用”.这里的明显缺陷是,如果我使用cookies,则不会与Cordova进行烘烤的cookie支持/存储,我建议您切换到HTML5本地存储.由于在移动设备上,我并不需要担心刷新页面,所以我可以让我的记忆体在记忆中活跃,并且随着我的策略而过期.
如果我采取这种方法,基于cookie的JWT桌面上的“承载”标题在移动上,我现在需要一个验证端点,将给予令牌两种不同的方式,当我在REST API方面授权时,我需要支持基于cookie的JWT(使用CSRF)和基于头文件的JWT验证.这个并发症让我很担心,因为我不知道我是否可以准确预见这里的安全隐患.
总结上面的想法：
>创建一个身份验证处理程序,将通过HttpOnly / Secure cookies发送令牌到桌面,以及移动的有效载荷.
>在我的REST API中,支持两种验证方法 – 基于头文件和基于cookie的方法,包括基于cookie的方法的CSRF保护.
有什么理由为什么我不想采取这种方法？我假设如果我在我的SPA上使用XSS作为严重的风险,那么我需要一个经典的登录页面进行身份验证来设置正确的cookie,因为如果我通过SPA进行身份验证,那么任何XSS攻击都可能会拦截它在手机和桌面上)！然而,在移动设备上,我需要将JWT注入到SPA中,也许可以通过一些自定义的DOM元素(Meta tag？)来实现,但是在这一点上,我可以让SPA执行登录,而不考虑XSS对移动设备的威胁.科尔多瓦将所有资产都包装到安装包中,以便稍微更好一点,但是为什么在桌面版本上不采取相同的方法呢？
我的应用程序用户输入很少,它主要是仪表板/报告工具.将会有一个“消息中心”,但它的内容应该始终是用户创建的(只有该用户)和消毒.在我的用例中,是否可以偏离“最佳做法”,并依靠本地存储不计算XSS作为我的SPA的严重风险？这将简化整个事情(按照原计划使用HTML5 sessionStorage),并降低复杂性,从而减少潜在安全漏洞的攻击面.我只想确保我在了解风险之前,才能向前迈进.
除了通过构建移动设备的本机应用程序,而不是使用Cordova将我的SPA转换为移动应用程序,还有没有安全的方法来使这个安全？我讨厌这样的情况,但可能会很好.
我会感谢所有关于这件事的想法！
就安全而言,无论您决定使用JWT还是简单的OAuth令牌,请确保所有通信都通过https.
请尽可能多地使用localStorage.
如果您考虑http请求的解剖结构,那么它真的是将一些基于文本的消息分成多个部分到服务器.请求的标题比其他任何部分(包括Cookie)更安全.因此,从安全角度来说,兴趣点是令牌的生成/验证/无效,令牌在设备上的存储以及请求的传输机制.
生成/验证/无效：在服务器上生成令牌.使用一些技术/策略来确保不存在碰撞或出血的可能性.此外,确保您的策略将允许您使服务器上的令牌无效,然后随后拒绝访问从服务器请求的数据,以进一步使用令牌.然后,在应用程序中,由服务器拒绝对资源的访问来处理用户UI行程.
>如何将令牌存储在设备上受制于设备操作系统使您可以使用的功能.关于使用本机应用程序是否比跨平台更好,我想创建一个native-cordova插件来使用任何特定的本地策略来存储您的令牌,如果不满足“开箱即用”(如本地存储),则是可能,虽然在我的经验中,这通常是过度的.如果任何人有不同的经历,很高兴得到纠正.
>请勿使用HTTPS始终使用所有Webservice终端通信.是HTTPS傻瓜,不,但你不会建立一个没有前门的房子,因为专门的窃贼可以学会选择锁.这大大保证了运输机制.
通常,这是所有本机应用程序都必须使用.
