我知道基于cookie的身份验证.可以应用SSL和HttpOnly标志来保护来自MITM和XSS的基于cookie的身份验证.但是,需要采取更多特殊措施以保护其免受CSRF的影响.它们有点复杂.(参考)
最近,我发现JSON Web Token(JWT)作为身份验证的解决方案非常热门.我知道有关编码,解码和验证JWT的内容.但是,我不明白为什么有些网站/教程在使用JWT时不需要CSRF保护.我已经阅读了很多,并试图总结下面的问题.我只是希望有人可以提供JWT的全貌并澄清我对JWT误解的概念.
如果JWT存储在cookie中,我认为它与基于cookie的身份验证相同,除了服务器不需要有会话来验证cookie /令牌.如果没有实施特殊措施,CSRF仍存在风险.JWT不是存储在cookie中吗？
如果JWT存储在localStorage/sessionStorage中,那么没有cookie所以不需要防止CRSF.问题是如何将JWT发送到服务器.我发现这里建议使用jQuery通过ajax请求的HTTP头发送JWT.那么,只有ajax请求才能进行身份验证吗？
此外,我发现还有一个博客节目使用"授权标题"和"承载"来发送JWT.我不明白博客谈论的方法.有人可以解释一下"授权标题"和"持票人"的更多信息吗？这是否使所有请求的HTTP头传输JWT？如果是的话,CSRF怎么样？
我意识到Spring安全性构建在过滤器链上,它将拦截请求,检测(缺少)身份验证,重定向到身份验证入口点或将请求传递给授权服务,并最终让请求命中servlet或抛出安全性异常(未经认证或未经授权).DelegatingFitlerProxy将这些过滤器粘合在一起.为了执行他们的任务,这些过滤器访问服务,例如UserDetailsService和AuthenticationManager.
链中的关键过滤器(按顺序)
我很困惑如何使用这些过滤器.对于弹簧提供的form-login,UsernamePasswordAuthenticationFilter仅用于/ login,而后者的过滤器不是？form-login名称空间元素是否自动配置这些过滤器？是否每个请求(已验证或未验证)都会到达非登录URL的FilterSecurityInterceptor？
如果我想使用从登录检索的JWT令牌来保护我的REST API ,该怎么办？我必须配置两个命名空间配置http标签,权限？另一个用于/ login with UsernamePasswordAuthenticationFilter,另一个用于REST url,带有自定义JwtAuthenticationFilter.
配置两个http元素会创建两个springSecurityFitlerChains吗？是UsernamePasswordAuthenticationFilter默认是关闭的,直到我宣布form-login？如何更换SecurityContextPersistenceFilter一个,Authentication从现有JWT-token而不是JSESSIONID？
我目前正在使用reactjs构建单页面应用程序.我读到很多不使用localStorage的原因是因为XSS漏洞.由于React逃脱了所有用户输入,现在使用localStorage是否安全？
(从这个线程产生,因为这实际上是一个问题,而不是NodeJS等)
我正在实现一个带有身份验证的REST API服务器,并且我已经成功实现了JWT令牌处理,以便用户可以使用用户名/密码通过/ login端口登录,在该端点上从服务器机密生成JWT令牌并返回到客户.然后,令牌在每个经过身份验证的API请求中从客户端传递到服务器,然后使用服务器机密来验证令牌.
但是,我正在努力了解有关如何以及在何种程度上验证令牌的最佳实践,以构建真正安全的系统.究竟什么应该参与"验证"令牌？是否可以使用server-secret验证签名,还是我还应该针对存储在服务器中的某些数据交叉检查令牌和/或令牌有效负载？
基于令牌的身份验证系统只会像在每个请求中传递用户名/密码一样安全,前提是获取令牌与获取用户密码相同或更困难.但是,在我看过的例子中,生成令牌所需的唯一信息是用户名和服务器端秘密.这不意味着假设一分钟恶意用户获得服务器机密的知识,他现在可以代表任何用户生成令牌,从而不仅可以访问一个给定用户,如果密码是获得了,但事实上对所有用户帐户？
这让我想到了一些问题:
1)JWT令牌验证是否应限于验证令牌本身的签名,单独依赖服务器机密的完整性,还是附带单独的验证机制？
在某些情况下,我已经看到了令牌和服务器会话的组合使用,在成功登录/ login端点后会建立会话.API请求验证令牌,并将令牌中找到的解码数据与会话中存储的某些数据进行比较.但是,使用会话意味着使用cookie,并且在某种意义上它违背了使用基于令牌的方法的目的.它也可能导致某些客户出现问题.
可以想象服务器将当前正在使用的所有令牌保存在内存缓存或类似内容中,以确保即使服务器机密被泄露,以便攻击者可以生成"有效"令牌,只有通过/ login端点生成的确切令牌会被接受.这是合理的还是只是多余/过度杀伤？
2)如果JWT签名验证是验证令牌的唯一方法,意味着服务器机密的完整性是一个突破点,那么应该如何管理服务器机密？从环境变量读取并在每个部署的堆栈中创建(随机化？)一次？定期重新创建或轮换(如果是这样,如何处理在轮换之前创建但需要在轮换之后进行验证的现有有效令牌,如果服务器在任何给定时间保持当前和之前的秘密,则可能就足够了) ？别的什么？
当谈到服务器机密被泄露的风险时,我可能只是过于偏执,这当然是一个需要在所有加密情况下解决的更普遍的问题......
网上有很多关于使用JWT(Json Web Token)进行身份验证的信息.但是,在多域环境中使用JWT令牌作为单点登录解决方案时,我仍然没有找到明确的解释.
我在一家公司工作,该公司在不同的主机上有很多站点.我们使用example1.com和example2.com.我们需要一个单点登录解决方案,这意味着如果用户在example1.com上进行身份验证,我们希望他也可以自动在example2.com上进行身份验证.
使用OpenId Connect流程,我了解想要在example1.com上进行身份验证的用户将首先被重定向到身份验证服务器(或OP"OpenId Provider").用户在该服务器上进行身份验证,然后使用签名的JWT令牌将其重定向回原始example1.com站点.(我知道有另一个流程返回一个中间令牌,以后可以将其交换为真正的JWT令牌,但我不认为这对我们来说是必需的)...
所以现在用户回到example1.com并进行身份验证!他可以发出请求,在Authentication标头中传递JWT令牌,服务器能够验证签名的JWT,因此能够识别用户.太好了!
第一个问题:
如何将JWT令牌存储在客户端上？还有很多关于此的信息,人们似乎同意使用Web Storage是走的路而不是好的旧路cookies.我们希望JWT在浏览器重启之间保持一致,所以让我们使用Local Storage,而不是Session Storage......
现在用户可以重新启动他的浏览器,只要JWT令牌没有过期,他仍然会在example1.com上进行身份验证!
此外,如果example1.com需要向我们的另一个域发出Ajax请求,我理解配置CORS会允许这样做.但我们的主要用例不是跨域请求,它有一个单点登录解决方案!
因此,主要问题是:
现在,流程应该是什么,如果用户访问example2.com并且我们希望他使用他已经拥有的JWT令牌进行身份验证？Local Storage似乎不允许跨域访问,所以此时浏览器无法读取JWT令牌以向example2.com发出请求!
应该 :
我觉得我在这里服用疯狂的药片.通常,对于任何给定的任务,总有一百万个库和样本浮动在网络上.我试图通过使用JSON网络令牌(JWT)的描述来实现与谷歌的"服务帐户"验证这里.
但是,只有PHP,Python和Java中的客户端库.即使在Google认证之外搜索JWT示例,JWT概念也只有蟋蟀和草稿.这真的是新的,可能是谷歌专有系统吗？
我可以设法解释的最接近的Java样本看起来非常密集和令人生畏.在C#中必须有一些我至少可以开始的东西.任何帮助都会很棒!
我正在Angular中编写一个webapp,其中身份验证由JWT令牌处理,这意味着每个请求都有一个带有所有必要信息的"身份验证"标头.
这适用于REST调用,但我不明白我应该如何处理后端托管的文件的下载链接(这些文件驻留在托管webservices的同一服务器上).
我不能使用常规<a href='...'/>链接,因为它们不会携带任何标头,验证将失败.同样的各种咒语window.open(...).
我想到的一些解决方案:
以上所有都不太令人满意.
1是我现在使用的解决方案.我不喜欢它有两个原因:首先它不是理想的安全性,其次它可以工作,但它需要相当多的工作,特别是在服务器上:下载一些我需要调用一个生成一个新"随机"的服务"url,将它存储在某个地方(可能在数据库上)一段时间,并将其返回给客户端.客户端获取URL,并使用window.open或类似的.请求时,新URL应检查它是否仍然有效,然后返回数据.
2似乎至少同样多的工作.
3看起来很多工作,甚至使用可用的库,以及许多潜在的问题.(我需要提供自己的下载状态栏,将整个文件加载到内存中,然后要求用户在本地保存文件).
这个任务似乎是一个非常基本的任务,所以我想知道是否有更简单的东西我可以使用.
我不一定在寻找"Angular方式"的解决方案.常规Javascript会没事的.
我一直在使用JWT库来解码Json Web Token,并希望切换到Microsoft的官方JWT实现System.IdentityModel.Tokens.Jwt.
文档非常稀疏,所以我很难弄清楚如何完成我在JWT库中所做的工作.使用JWT库,有一个Decode方法,它采用base64编码的JWT并将其转换为JSON,然后可以对其进行反序列化.我想使用System.IdentityModel.Tokens.Jwt做类似的事情,但经过大量的挖掘,无法弄清楚如何.
为了它的价值,我正在从cookie中读取JWT令牌,以便与Google的身份框架一起使用.
任何帮助,将不胜感激.
我正在我的身份验证服务器中实现OAuth 2.0 JWT access_token.但是,我不清楚JWT"aud"声明与client_id http标头值之间的差异.它们是一样的吗？如果没有,你能解释两者之间的区别吗？
我怀疑"aud"应该引用资源服务器,而client_id应该引用认证服务器识别的客户端应用程序之一(即web应用程序或IOS应用程序).
在我目前的情况下,我的资源服务器也是我的Web应用程序客户端.