精华内容
下载资源
问答
  • 基于JWT实现的单点登录系统,使用idea开发的,可以供学习参考,有什么问题可以咨询
  • 主要介绍了Spring Security基于JWT实现SSO单点登录详解,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
  • 原文:http://blog.leapoahead.com/2015/09/07/user-authentication-with-jwt/上次在《JSON Web Token - 在Web应用间安全地传递信息》中我提到了JSON Web Token可以用来设计单点登录系统。我尝试用八幅漫画先让大家...

    原文:http://blog.leapoahead.com/2015/09/07/user-authentication-with-jwt/

    上次在《JSON Web Token - 在Web应用间安全地传递信息》中我提到了JSON Web Token可以用来设计单点登录系统。我尝试用八幅漫画先让大家理解如何设计正常的用户认证系统,然后再延伸到单点登录系统。

    如果还没有阅读《JSON Web Token - 在Web应用间安全地传递信息》,我强烈建议你花十分钟阅读它,理解JWT的生成过程和原理。

    用户认证八步走

    所谓用户认证(Authentication),就是让用户登录,并且在接下来的一段时间内让用户访问网站时可以使用其账户,而不需要再次登录的机制。

    小知识:可别把用户认证和用户授权(Authorization)搞混了。用户授权指的是规定并允许用户使用自己的权限,例如发布帖子、管理站点等。

    首先,服务器应用(下面简称“应用”)让用户通过Web表单将自己的用户名和密码发送到服务器的接口。这一过程一般是一个HTTP POST请求。建议的方式是通过SSL加密的传输(https协议),从而避免敏感信息被嗅探。


    接下来,应用和数据库核对用户名和密码。


    核对用户名和密码成功后,应用将用户的 id(图中的 user_id)作为JWT Payload的一个属性,将其与头部分别进行Base64编码拼接后签名,形成一个JWT。这里的JWT就是一个形同 lll.zzz.xxx的字符串。


    应用将JWT字符串作为该请求Cookie的一部分返回给用户。注意,在这里必须使用 HttpOnly属性来防止Cookie被JavaScript读取,从而避免跨站脚本攻击(XSS攻击)。


    在Cookie失效或者被删除前,用户每次访问应用,应用都会接受到含有 jwt的Cookie。从而应用就可以将JWT从请求中提取出来。


    应用通过一系列任务检查JWT的有效性。例如,检查签名是否正确;检查Token是否过期;检查Token的接收方是否是自己(可选)。


    应用在确认JWT有效之后,JWT进行Base64解码(可能在上一步中已经完成),然后在Payload中读取用户的id值,也就是 user_id属性。这里用户的 id为1025。


    应用从数据库取到 id为1025的用户的信息,加载到内存中,进行ORM之类的一系列底层逻辑初始化。


    应用根据用户请求进行响应。


    和Session方式存储id的差异

    Session方式存储用户id的最大弊病在于要占用大量服务器内存,对于较大型应用而言可能还要保存许多的状态。一般而言,大型应用还需要借助一些KV数据库和一系列缓存机制来实现Session的存储。

    而JWT方式将用户状态分散到了客户端中,可以明显减轻服务端的内存压力。除了用户id之外,还可以存储其他的和用户相关的信息,例如该用户是否是管理员、用户所在的分桶(见[《你所应该知道的A/B测试基础》一文](/2015/08/27/introduction-to-ab-testing/)等。

    虽说JWT方式让服务器有一些计算压力(例如加密、编码和解码),但是这些压力相比磁盘I/O而言或许是半斤八两。具体是否采用,需要在不同场景下用数据说话。

    单点登录

    Session方式来存储用户id,一开始用户的Session只会存储在一台服务器上。对于有多个子域名的站点,每个子域名至少会对应一台不同的服务器,例如:

    • www.taobao.com

    • nv.taobao.com

    • nz.taobao.com

    • login.taobao.com

    所以如果要实现在 login.taobao.com登录后,在其他的子域名下依然可以取到Session,这要求我们在多台服务器上同步Session。

    使用JWT的方式则没有这个问题的存在,因为用户的状态已经被传送到了客户端。因此,我们只需要将含有JWT的Cookie的 domain设置为顶级域名即可,例如

    
    
    1. Set-Cookie: jwt=lll.zzz.xxx; HttpOnly; max-age=980000; domain=.taobao.com

    注意 domain必须设置为一个点加顶级域名,即 .taobao.com。这样,taobao.com和*.taobao.com就都可以接受到这个Cookie,并获取JWT了。


    展开全文
  • 前言: spring boot security oauth2 jwt整合,搭建一个SSO单点登录系统,认证服务和资源服务分离… github地址: https://github.com/qiangqiang666/oauth2

    前言:
    spring boot security oauth2 jwt整合,搭建一个SSO单点登录系统,认证服务和资源服务分离…

    github地址: 项目地址

    展开全文
  • 自从上次研究过JWT如何应用于会话管理,加之以前的项目中也一直在使用CAS这个比较流行的单点登录框架,所以就一直在琢磨如何能够把JWT跟单点登录结合起来一起使用,尽量能把两种技术的优势都集成到项目中来。...

    单点登录是我比较喜欢的一个技术解决方案,一方面他能够提高产品使用的便利性,另一方面他分离了各个应用都需要的登录服务,对性能以及工作量都有好处。自从上次研究过JWT如何应用于会话管理,加之以前的项目中也一直在使用CAS这个比较流行的单点登录框架,所以就一直在琢磨如何能够把JWT跟单点登录结合起来一起使用,尽量能把两种技术的优势都集成到项目中来。本文介绍我从CAS思考得出的SSO的实现方案。

    前言

    其实CAS这个方案很好,非常强大,它最新的版本已经集成JWT了,所以要是不想自己开发单点登录的服务的话,完全可以考虑使用CAS。但是我认为,我们在做项目的时候,也许一开始并不需要这么强大的产品,CAS提供的登录形式有很多,而我们只需要应用其中的一种;而且它这个框架正是因为强大,所以也会比较复杂,简单上手容易,但是遇到一些特殊的需求,比如我们想在CAS里面加入微信登录,那就需要对它的原理以及API有比较深入的了解才行。综合考虑,还是弄清楚CAS的原理,自己来实现一个基本的SSO服务比较放心。

    本文的内容需要对JWT和SSO有一个基本的了解,你可以从这两篇文章来了解JWT的用途:3种web会话管理的方式JWT实现token-based会话管理,还可以从下面的资料来了解SSO的内容:SSO_百度百科

    方案介绍

    本文主要是通过时序图的方式来介绍JWT SSO的实现原理,具体的技术实现暂时还没有,不过当你理解了这个方案的原理后,你会觉得最终的实现并不会特别复杂,你可以用任意的平台语言来实现它。下面的时序图,模拟了三个服务,分别是CAS、系统A、系统B,它们分别部署在cas.com,systemA.com和systemB.com;CAS这个服务用来管理SSO的会话;系统A和系统B代表着实际的业务系统。我从五个场景分别来说明这个SSO方案的实现细节。下面先来看第一个。

    场景一:用户发起对业务系统的第一次访问,假设他第一次访问的是系统A的some/page这个页面,它最终成功访问到这个页面的过程是:

    sso_1

    在这个过程里面,我认为理解的关键点在于:

    1. 它用到了两个cookie(jwt和sid)和三次重定向来完成会话的创建和会话的传递;

    1. jwt的cookie是写在systemA.com这个域下的,所以每次重定向到systemA.com的时候,jwt这个cookie只要有就会带过去;

    2. sid的cookie是写在cas.com这个域下的,所以每次重定向到cas.com的时候,sid这个cookie只要有就会带过去;

    3. 在验证jwt的时候,如何知道当前用户已经创建了sso的会话?因为jwt的payload里面存储了之前创建的sso 会话的session id,所以当cas拿到jwt,就相当于拿到了session id,然后用这个session id去判断有没有的对应的session对象即可。

    还要注意的是:CAS服务里面的session属于服务端创建的对象,所以要考虑session id唯一性以及session共享(假如CAS采用集群部署的话)的问题。session id的唯一性可以通过用户名密码加随机数然后用hash算法如md5简单处理;session共享,可以用memcached或者redis这种专门的支持集群部署的缓存服务器管理session来处理。

    由于服务端session具有生命周期的特点,到期需自动销毁,所以不要自己去写session的管理,免得引发其它问题,到github里找开源的缓存管理中间件来处理即可。存储session对象的时候,只要用session id作为key,session对象本身作为value,存入缓存即可。session对象里面除了session id,还可以存放登录之后获取的用户信息等业务数据,方便业务系统调用的时候,从session里面返回会话数据。

    场景二:用户登录之后,继续访问系统A的其它页面,如some/page2,它的处理过程是:

    sso_2

    从这一步可以看出,即使登录之后,也要每次跟CAS校验jwt的有效性以及会话的有效性,其实jwt的有效性也可以放在业务系统里面处理的,但是会话的有效性就必须到CAS那边才能完成了。当CAS拿到jwt里面的session id之后,就能到session 缓存服务器里面去验证该session id对应的session对象是否存在,不存在,就说明会话已经销毁了(退出)。

    场景三:用户登录了系统A之后,再去访问其他系统如系统B的资源,比如系统B的some/page,它最终能访问到系统B的some/page的流程是:

    sso_3

    这个过程的关键在于第一次重定向的时候,它会把sid这个cookie带回给CAS服务器,所以CAS服务器能够判断出会话是否已经建立,如果已经建立就跳过登录页的逻辑。

    场景四:用户继续访问系统B的其它资源,如系统B的some/page2:

    sso_4

    这个场景的逻辑跟场景二完全一致。

    场景五:退出登录,假如它从系统B发起退出,最终的流程是:

    sso_5

    最重要的是要清除sid的cookie,jwt的cookie可能业务系统都有创建,所以不可能在退出的时候还挨个去清除那些系统的cookie,只要sid一清除,那么即使那些jwt的cookie在下次访问的时候还会被传递到业务系统的服务端,由于jwt里面的sid已经无效,所以最后还是会被重定向到CAS登录页进行处理。

    方案总结

    以上方案两个关键的前提:

    1. 整个会话管理其实还是基于服务端的session来做的,只不过这个session只存在于CAS服务里面;

    2. CAS之所以信任业务系统的jwt,是因为这个jwt是CAS签发的,理论上只要认证通过,就可以认为这个jwt是合法的。

    jwt本身是不可伪造,不可篡改的,但是不代表非法用户冒充正常用法发起请求,所以常规的几个安全策略在实际项目中都应该使用:

    1. 使用https

    2. 使用http-only的cookie,针对sid和jwt

    3. 管理好密钥

    4. 防范CSRF攻击。

    尤其是CSRF攻击形式,很多都是钻代码的漏洞发生的,所以一旦出现CSRF漏洞,并且被人利用,那么别人就能用获得的jwt,冒充正常用户访问所有业务系统,这个安全问题的后果还是很严重的。考虑到这一点,为了在即使有漏洞的情况将损害减至最小,可以在jwt里面加入一个系统标识,添加一个验证,只有传过来的jwt内的系统标识与发起jwt验证请求的服务一致的情况下,才允许验证通过。这样的话,一个非法用户拿到某个系统的jwt,就不能用来访问其它业务系统了。

    在业务系统跟CAS发起attach/validate请求的时候,也可以在CAS端做些处理,因为这个请求,在一次SSO过程中,一个系统只应该发一次,所以只要之前已经给这个系统签发过jwt了,那么后续 同一系统的attach/validate请求都可以忽略掉。

    总的来说,这个方案的好处有:

    1. 完全分布式,跨平台,CAS以及业务系统均可采用不同的语言来开发;

    2. 业务系统如系统A和系统B,可实现服务端无状态

    3. 假如是自己来实现,那么可以轻易的在CAS里面集成用户注册服务以及第三方登录服务,如微信登录等。

    它的缺陷是:

    1. 第一次登录某个系统,需要三次重定向(不过可以优化成两次);

    2. 登录后的后续请求,每次都需要跟CAS进行会话验证,所以CAS的性能负载会比较大

    3. 登陆后的后续请求,每次都跟CAS交互,也会增加请求响应时间,影响用户体验。

    本文小结

    本文从理论层面介绍了结合jwt来实现SSO的方案原理,希望它能帮助一些朋友更好的理解SSO以及它的实现方法。本文方案参考自CAS的实现流程,你可以从下面这个资料了解CAS的单点登录实现过程:

    https://apereo.github.io/cas/4.1.x/protocol/CAS-Protocol.html

    它的流程跟我这个差别不是特别大,但是从清晰层面来说,我写的还是要更明了一些,所以对比起来阅读,可能理解会更透彻些。

    另外,这个方案考虑地不一定很全面,所以要是您发现了其中的问题,还请您帮忙指正,非常感谢:)

    如果您觉得本文对你有用,不妨帮忙点个赞,或者在评论里给我一句赞美,小小成就都是今后继续为大家编写优质文章的动力,流云拜谢! 欢迎您持续关注我的博客:)
    展开全文
  • 上次在《JSON Web Token - 在Web应用间安全地传递信息》中我提到了JSON Web Token可以用来设计单点登录系统。我尝试用八幅漫画先让大家理解如何设计正常的用户认证系统,然后再延伸到单点登录系统。 如果还没有阅读...

    上次在《JSON Web Token - 在Web应用间安全地传递信息》中我提到了JSON Web Token可以用来设计单点登录系统。我尝试用八幅漫画先让大家理解如何设计正常的用户认证系统,然后再延伸到单点登录系统。

    如果还没有阅读《JSON Web Token - 在Web应用间安全地传递信息》,我强烈建议你花十分钟阅读它,理解JWT的生成过程和原理。

    用户认证八步走

    所谓用户认证(Authentication),就是让用户登录,并且在接下来的一段时间内让用户访问网站时可以使用其账户,而不需要再次登录的机制。

    小知识:可别把用户认证和用户授权(Authorization)搞混了。用户授权指的是规定并允许用户使用自己的权限,例如发布帖子、管理站点等。

    首先,服务器应用(下面简称“应用”)让用户通过Web表单将自己的用户名和密码发送到服务器的接口。这一过程一般是一个HTTP POST请求。建议的方式是通过SSL加密的传输(https协议),从而避免敏感信息被嗅探。

    img

    接下来,应用和数据库核对用户名和密码。

    img

    核对用户名和密码成功后,应用将用户的id(图中的user_id)作为JWT Payload的一个属性,将其与头部分别进行Base64编码拼接后签名,形成一个JWT。这里的JWT就是一个形同lll.zzz.xxx的字符串。

    img

    应用将JWT字符串作为该请求Cookie的一部分返回给用户。注意,在这里必须使用HttpOnly属性来防止Cookie被JavaScript读取,从而避免跨站脚本攻击(XSS攻击)

    img

    在Cookie失效或者被删除前,用户每次访问应用,应用都会接受到含有jwt的Cookie。从而应用就可以将JWT从请求中提取出来。

    img

    应用通过一系列任务检查JWT的有效性。例如,检查签名是否正确;检查Token是否过期;检查Token的接收方是否是自己(可选)。

    img

    应用在确认JWT有效之后,JWT进行Base64解码(可能在上一步中已经完成),然后在Payload中读取用户的id值,也就是user_id属性。这里用户的id为1025。

    img

    应用从数据库取到id为1025的用户的信息,加载到内存中,进行ORM之类的一系列底层逻辑初始化。

    img

    应用根据用户请求进行响应。

    img

    和Session方式存储id的差异

    Session方式存储用户id的最大弊病在于要占用大量服务器内存,对于较大型应用而言可能还要保存许多的状态。一般而言,大型应用还需要借助一些KV数据库和一系列缓存机制来实现Session的存储。

    而JWT方式将用户状态分散到了客户端中,可以明显减轻服务端的内存压力。除了用户id之外,还可以存储其他的和用户相关的信息,例如该用户是否是管理员、用户所在的分桶(见[《你所应该知道的A/B测试基础》一文](/2015/08/27/introduction-to-ab-testing/)等。

    虽说JWT方式让服务器有一些计算压力(例如加密、编码和解码),但是这些压力相比磁盘I/O而言或许是半斤八两。具体是否采用,需要在不同场景下用数据说话。

    单点登录

    Session方式来存储用户id,一开始用户的Session只会存储在一台服务器上。对于有多个子域名的站点,每个子域名至少会对应一台不同的服务器,例如:

    所以如果要实现在login.taobao.com登录后,在其他的子域名下依然可以取到Session,这要求我们在多台服务器上同步Session。

    使用JWT的方式则没有这个问题的存在,因为用户的状态已经被传送到了客户端。因此,我们只需要将含有JWT的Cookie的domain设置为顶级域名即可,例如

    Set-Cookie: jwt=lll.zzz.xxx; HttpOnly; max-age=980000; domain=.taobao.com
    

    注意domain必须设置为一个点加顶级域名,即.taobao.com。这样,taobao.com和*.taobao.com就都可以接受到这个Cookie,并获取JWT了。

    展开全文
  • 来自:https://u.nu/2k4wkJSON Web Token(JWT)是一个非常轻巧的规范。这个规范允许我们使用JWT在用户和服务器之间传递安全可靠的信息。让我们来假想一下一个场...
  • JWT单点登录

    千次阅读 2021-02-24 09:10:11
    单点登录是什么 SSO(Single Sign On)SSO的定义是在个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。 为什么需要单点登录 以前分布式系统个相关的应用系统,都需要分别进行登录,非常繁琐...
  • 自从上次研究过JWT如何应用于会话管理,加之以前的项目中也一直在使用CAS这个比较流行的单点登录框架,所以就一直在琢磨如何能够把JWT跟单点登录结合起来一起使用,尽量能把两种技术的优势都集成到项目中来。...
  • 使用JWT实现单点登录(完全跨域方案)

    万次阅读 多人点赞 2018-09-10 15:57:56
    首先介绍一下什么是JSON Web Token(JWT)? 官方文档是这样解释的:JSON Web Token(JWT)是一个开放标准(RFC 7519),它定义了一种紧凑且独立的方式,可以在各方之间作为JSON对象安全地传输信息。此信息可以通过...
  • 所谓用户认证(Authentication),就是让用户登录,并且在接下来的一段时间内让用户访问网站时可以使用其账户,而不需要再次登录的机制。 小知识:可别把用户认证和用户授权(Authorization)搞混了。
  • 主要介绍了spring boot如何基于JWT实现单点登录详解,用户只需登录一次就能够在这两个系统中进行操作。很明显这就是单点登录(Single Sign-On)达到的效果,需要的朋友可以参考下
  • 使用jwt完成sso单点登录

    万次阅读 2018-12-17 15:12:41
    JWT 在了解jwt之前,先了解一下常用的会话管理 基于server-session的管理方式 cookie-based的管理方式 token-based的管理方式 一.基于server-session的管理 服务端session是用户第一次访问应用时,服务器就会...
  • 原文链接:...JWT 在了解jwt之前,先了解一下常用的会话管理 基于 server-session 的管理方式 cookie-based 的管理方式...
  • 使用jwt技术实现系统间的单点登录

    万次阅读 2017-05-26 17:21:04
    下面介绍用jwt技术如何来实现单点登录。 一、JWT定义及其组成 JWT(JSON WEB TOKEN)是一个非常轻巧的规范,这个规范允许我们使用jwt在客户端和服务器之间传递安全可靠的信息。 JWT由3个部分组成,分别是头部、...
  • JSON Web Token(JWT)是一个非常轻巧的规范。这个规范允许我们使用JWT在用户和服务器之间传递安全可靠的信息。让我们来假想一下一个场景。在A用户关注了B用户的时候,系统发邮件...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 8,422
精华内容 3,368
关键字:

jwt多系统单点登录