单点登录

真的如老话所说，“没有笨的人，只有懒得人”。前段时间时间需要和其他项目做cas集成，于是乎在网上找了几篇教程看了一下，好了，很简单，学会了，开搞（自以为研究明白）。集成完事了，登录成功了，自以为这就过去了。然而，没过几天就出bug了，这下惨了，当初没有好好学出了问题都不知道咋解决。无奈，只得静下心来好好学习一番（当初太懒付出的代价）。原理其实很简单的，只要耐下心来好好研究终会搞懂的。 先看下图那么是如何验证用户是否登录过呢？ 如果session中包含“ const_cas_assertion ”属性，说明已经登录，跳过此过滤器执行配置的其他过滤器； 如果ticket参数不为空（可能是登陆后跳转回来的），跳过此过滤器，执行TicketValidationFilter 验证ticket； 如果前两个条件都不满足，重定向到cas服务端，返回登录页面进行登录操作。Cookie中的CASTGC：向cookie中添加该值的目的是当下次访问 www.cas.server.com 时，浏览器将Cookie中的TGC携带到服务器，服务器根据这个TGC，查找与之对应的TGT。从而判断用户是否登录过了，是否需要展示登录页面。TGT与TGC的关系就像SESSION与Cookie中SESSIONID的关系。 TGT：Ticket Granted Ticket（俗称大令牌，或者说票根，他可以签发ST）。 TGC：Ticket Granted Cookie（cookie中的value），存在Cookie中，根据他可以找到TGT。 ST：Service Ticket （小令牌），是TGT生成的，默认是用一次就生效了。也就是上面的ticket值。 为了加深理解，也为了以后作参考，整理记录。另外，还要说一句，不要偷懒，多动手多动脑！

从业务用户视角来看，IT系统越来越多，导致帐号信息越来越多，业务人员需要记录多个业务系统的认证信息，使用复杂性会越来越大 。从管理员视角来看，IT系统越来越多，管理员维护帐号的成本越来越大，容易产生安全隐患。东软SaCa IAM 统一身份认证平台，可以了解一下，官网：https://platform.neusoft.com/

如果我们的网站需要和另一个域名做统一认证，也就是在我们网站登录，但真正的功能却在另一个网站来提供。许多都以 passport 的方式。 整个认证可以分三步完成 第一步：本地验证 这个很简单，输入本地的用户名和密码，然后服务器认证通过，并返回正确的Cookie; 第二步：做远程认证，并返回远程连接 通过本地Cookie,确认用户合法性，然后服务器端调用远程的登录程序，返回一个远程认证号的URL,这个URL里面包含了一个唯一的认证码，使用Location的方式 第三步：远程登录 客户端使用前一步的URL,访问远程的服务器，服务器确认认证码的正确性，再返回正确的远程Cookie. 至此，本地认证，通过一个URL,实现了远程认证。

公司的SSO采用CAS机制，机制说明： https://www.jianshu.com/p/083c0597e7e0 ant design pro接入SSO时，也踩了一些坑 一、应用服务端 服务端使用了spring boot，spring boot跟CAS的整合可以参考文档： https://blog.csdn.net/jw314947712/article/details/54236216 二、前端 这里有几个坑需要注意： 1、ajax请求返回SSO登录页面，需要修改跳转模式为手动跳转。 2、由于SSO域名与前端域名不同，ajax请求结果并不会出现302返回码。 修改utils下面的request.js文件，设置跳转模式为手动跳转 然后在response里面拦截

昨天碰到了一篇讲单点登录（SSO）的文章，作者可能是从字面意思理解的单点登录（只允许一个地方登录，一方登陆了，另一方就要下线，这种应该是单设备登录）。正好最近我也在处理多系统访问的问题，也要用到单点登录，就打算整理点东西。 单点登录： 英文Single Sign On，根据英文含义不难理解，即：单一标记（单点）登录。就是说，我只需要登录一次。例如：QQ，我在QQ空间登录一次，我可以去访问QQ产品的其他服务：QQ邮箱、腾讯新闻等，都能保证你的账户保持登录状态。 单设备登录： 就是只能在一个设备上登录，若同时在其他设备登录，先前登录的用户会被提醒：该账户在其他设备登录。例如qq，小米手机登录中，同时拿华为手机登录该账户，小米手机的账户会被挤下线。 SSO（Single Sign-On）是一种统一认证和授权机制，指访问同一服务器不同应用中的受保护资源的同一用户，只需要登录一次，即通过一个应用中的安全验证后，再访问其他应用中的受保护资源时，不再需要重新登录验证。 解决了用户只需要登录一次就可以访问所有相互信任的应用系统，而不用重复登录。 如下图所示： 当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份效验，如果通过效验，应该返回给用户一个认证的凭据－－ticket；用户再访问别的应用的时候，就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行效验，检查ticket的合法性（4,6）。如果通过效验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。 从上图可以看出sso的实现技术点： 1）所有应用系统共享 一个身份认证系统 。 统一的认证系统是SSO的前提之一。 认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。 另外，认证系统还应该对ticket进行效验，判断其有效性。 2）所有应用系统能够识别和提取ticket信息 要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。 应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。 关于 统一身份认证机制 ：如下图 ①用户请求访问业务系统。 ②业务系统在系统中查看是否有对应请求的有效令牌，若有，则读取对应的身份信息，允许其访问；若没有或令牌无效，则把用户重定向到统一身份认证平台，并携带业务系统地址，进入第③步。 ③在统一身份认证平台提供的页面中，用户输入身份凭证信息，平台验证此身份凭证信息，若有效，则生成一个有效的令牌给用户，进入第④步；若无效，则继续进行认证，直到认证成功或退出为止。 ④用户携带第③步获取的令牌，再次访问业务系统。 ⑤业务系统获取用户携带的令牌，提交到认证平台进行有效性检查和身份信息获取。 ⑥若令牌通过有效性检查，则认证平台会把令牌对应的用户身份信息返回给业务系统，业务系统把身份信息和有效令牌写入会话状态中，允许用户以此身份信息进行业务系统的各种操作；若令牌未通过有效性检查，则会再次重定向到认证平台，返回第③步。 1）提高用户的效率。 用户不再被多次登录困扰，也不需要记住多个 ID 和密码。另外，用户忘记密码并求助于支持人员的情况也会减少。 2）提高开发人员的效率。 SSO 为开发人员提供了一个通用的身份验证框架。 实际上，如果 SSO 机制是独立的，那么开发人员就完全不需要为身份验证操心。 他们可以假设，只要对应用程序的请求附带一个用户名，身份验证就已经完成了。 3）简化管理。 如果应用程序加入了单点登录协议，管理用户帐号的负担就会减轻。 简化的程度取决于应用程序，因为 SSO 只处理身份验证。 所以，应用程序可能仍然需要设置用户的属性（比如访问特权）。 1）不利于重构 因为涉及到的系统很多，要重构必须要兼容所有的系统，可能很耗时 2） 无人看守桌面 因为只需要登录一次，所有的授权的应用系统都可以访问，可能导致一些很重要的信息泄露。

像日常提到的SaaS、ERP、OA等各种软件，通过玉符科技单点登录SSO实现统一认证，省去了一个个系统登录的繁杂，同时也给IT运维人员提高了工作效率，节约人力成本。

单点登录 ：简称为 SSO，是比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。 简单来说 ，一个公司有多个应用，都要进行注册登录，退出的时候又要一个个退出。用户体验很不好。单点登录可以实现：登录的时候只要一次登录，退出的时候只要一次退出。 采用LocalStorage存储token, 但localStorage不支持跨域，则需要登录一个网页时，需要在本网页在localStorage时，也需要为其他的页面写入相应的token. 扩充

其实单点登录的概念并不复杂，单独登录 (SSO)其实就是让用户通过一次登录访问授权的网络资源。不知道这样的答案您是否满意。目前最单点登录的公司其实是有一些的，但是真正有技术实力的其实并不是很多。如果说非得推荐一家的话，比如玉符科技SSO，我了解了一下，他们的产品还是不错的。你的第三个问题，其实可以这样和老板沟通，日常提到的SaaS、ERP、OA等各种软件，通过玉符科技单点登录SSO实现统一认证，一次登录就可全部查看操作，省去了一个个系统登录的繁杂，同时也给IT运维人员提高了工作效率，节约人力成本。

首先，实现了单点登录后，是将系统A和系统B已经统一到一个页面上，俗称portal；当用户登录到这个页面上时，就可以看到自己被授权的系统；当然，需要统一身份数据源后也就是将两套系统中的身份信息集成到一起，就可以给用户跟进不同的需求或者部门来分配应用系统；比如用户user只有系统A的权限，那么当他登录到门户上时，也就只能看到系统A，此时他并没有系统B的任何权限，如果他需要开通B的权限，需要通过管理员去开通；这些功能都是可以通过玉符科技的IDAAS平台来进行，实现统一身份数据源、单点登录，一键入离职等功能。问题中涉及到的权限、集成、单点等问题都可以很好的解决。

在企业发展初期，企业使用的系统很少，通常一个或者两个，每个系统都有自己的登录模块，运营人员每天用自己的账号登录，很方便。 但随着企业的发展，用到的系统随之增多，运营人员在操作不同的系统时，需要多次登录，而且每个系统的账号都不一样，这对于运营人员 来说，很不方便。于是，就想到是不是可以在一个系统登录，其他系统就不用登录了呢？这就是单点登录要解决的问题。 单点登录英文全称Single Sign On，简称就是SSO。它的解释是：在多个应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统。 如图所示，图中有4个系统，分别是Application1、Application2、Application3、和SSO。Application1、Application2、Application3没有登录模块，而SSO只有登录模块，没有其他的业务模块，当Application1、Application2、Application3需要登录时，将跳到SSO系统，SSO系统完成登录，其他的应用系统也就随之登录了。这完全符合我们对单点登录（SSO）的定义。 在说单点登录（SSO）的技术实现之前，我们先说一说普通的登录认证机制。 如上图所示，我们在浏览器（Browser）中访问一个应用，这个应用需要登录，我们填写完用户名和密码后，完成登录认证。这时，我们在这个用户的session中标记登录状态为yes（已登录），同时在浏览器（Browser）中写入Cookie，这个Cookie是这个用户的唯一标识。下次我们再访问这个应用的时候，请求中会带上这个Cookie，服务端会根据这个Cookie找到对应的session，通过session来判断这个用户是否登录。如果不做特殊配置，这个Cookie的名字叫做jsessionid，值在服务端（server）是唯一的。 一个企业一般情况下只有一个域名，通过二级域名区分不同的系统。比如我们有个域名叫做：a.com，同时有两个业务系统分别为：app1.a.com和app2.a.com。我们要做单点登录（SSO），需要一个登录系统，叫做：sso.a.com。 我们只要在sso.a.com登录，app1.a.com和app2.a.com就也登录了。通过上面的登陆认证机制，我们可以知道，在sso.a.com中登录了，其实是在sso.a.com的服务端的session中记录了登录状态，同时在浏览器端（Browser）的sso.a.com下写入了Cookie。那么我们怎么才能让app1.a.com和app2.a.com登录呢？这里有两个问题： 那么我们如何解决这两个问题呢？针对第一个问题，sso登录以后，可以将Cookie的域设置为顶域，即.a.com，这样所有子域的系统都可以访问到顶域的Cookie。我们在设置Cookie时，只能设置顶域和自己的域，不能设置其他的域。比如：我们不能在自己的系统中给baidu.com的域设置Cookie。 Cookie的问题解决了，我们再来看看session的问题。我们在sso系统登录了，这时再访问app1，Cookie也带到了app1的服务端（Server），app1的服务端怎么找到这个Cookie对应的Session呢？这里就要把3个系统的Session共享，如图所示。共享Session的解决方案有很多，例如：Spring-Session。这样第2个问题也解决了。 同域下的单点登录就实现了，但这还不是真正的单点登录。 同域下的单点登录是巧用了Cookie顶域的特性。如果是不同域呢？不同域之间Cookie是不共享的，怎么办？ 这里我们就要说一说CAS流程了，这个流程是单点登录的标准流程。 上图是CAS官网上的标准流程，具体流程如下： 至此，跨域单点登录就完成了。以后我们再访问app系统时，app就是登录的。接下来，我们再看看访问app2系统时的流程。 这样，app2系统不需要走登录流程，就已经是登录了。SSO，app和app2在不同的域，它们之间的session不共享也是没问题的。 有的同学问我，SSO系统登录后，跳回原业务系统时，带了个参数ST，业务系统还要拿ST再次访问SSO进行验证，觉得这个步骤有点多余。他想SSO登录认证通过后，通过回调地址将用户信息返回给原业务系统，原业务系统直接设置登录状态，这样流程简单，也完成了登录，不是很好吗？ 其实这样问题时很严重的，如果我在SSO没有登录，而是直接在浏览器中敲入回调的地址，并带上伪造的用户信息，是不是业务系统也认为登录了呢？这是很可怕的。 单点登录（SSO）的所有流程都介绍完了，原理大家都清楚了。总结一下单点登录要做的事情： 参考自己写的【关于JWT/TOKEN】文章

因为AB两个系统都用了一个用户表，只需要在用户表里反过来做就可以，在AB两个系统里都禁止对方系统的用户访问即可。

SSO的基本概念SSO英文全称Single Sign On（单点登录）。SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。它是目前比较流行的企业业务整合的解决方案之一。（本段内容来自百度百科）今天这篇文章将介绍SSO的一种实现方式，代码超简单，仅用来验证我的思路是否可行，具体细节请大家来完善！二级域名的单点登录什么是二级域名呢？例如： site1.domain.com site2.domain.com对于二级域名的单点登录，我们可以非常方便的通过共享cookie来实现，简单的说，就是在设置Form票据的时候，将cookie的domain设置为顶级域名即可，例如：HttpCookie cookie = new HttpCookie(FormsAuthCookieName, encryptedTicket);cookie.Expires = rememberMe ? expirationDate : DateTime.MinValue;cookie.HttpOnly = true;cookie.Path = "/";cookie.Domain = "domain.com";context.Response.Cookies.Set(cookie);这种方式不涉及跨域，当cookie的domain属性设置为顶级域名之后，所有的二级域名都可以访问到身份验证的cookie，在服务器端只要验证了这个cookie就可以实现身份的验证。但是，当跨域的时候，例如： site1.com site2.com这个时候就不能共享cookie了，所以上面的解决方案就会失效。那么，要实现跨域的单点登录该如何做呢？请继续往下看。跨域的单点登录关于跨域的SSO的设计思路，我画了一个简单的流程图：首先，我将跨域的SSO分为SSO-Server和SSO-Client两个部分，SSO-Client可以是多个的。SSO-ServerSSO-Server主要负责用户登录、注销、为SSO-Client分配taken、验证taken的工作。登录和注销采用的是Form认证方式，很多地方都有详细的介绍。SSO-Server分配Token为SSO-Client分配Token的部分，在SSO-Client请求SSO受信页面的时候，检查SSO-Server是否登录，如果没有登录则跳转到SSO-Server的登录页面，如果已登录，则执行分配Token的代码，在分配完成以后将TokenID作为参数添加到returnUrl中，并跳转到returnUrl，具体的分配代码如下：if (Domain.Security.SmartAuthenticate.LoginUser != null){ //生成Token，并持久化Token Domain.SSO.Entity.SSOToken token = new Entity.SSOToken(); token.User = new Entity.SSOUser(); token.User.UserName = Domain.Security.SmartAuthenticate.LoginUser.UserName; token.LoginID = Session.SessionID; Domain.SSO.Entity.SSOToken.SSOTokenList.Add(token); //拼接返回的url，参数中带Token string spliter = returnUrl.Contains("?") ? "&" : "?"; returnUrl = returnUrl + spliter + "token=" + token.ID; Response.Redirect(returnUrl);}当完成Token分配之后，页面将带有TokenID的参数跳转到SSO-Client页面，并在SSO-Client的Cookie中添加Token值，在以后的每次请求中，SSO-Client通过调用SSO-Server的服务来验证Token的合法性。SSO-Server验证Token我是通过WebService来验证Token的。首先在SSO-Server定义一个Web Service：[WebMethod]public Entity.SSOToken ValidateToken(string tokenID){ if (!KeepToken(tokenID)) return null; var token = Domain.SSO.Entity.SSOToken.SSOTokenList.Find(m => m.ID == tokenID); return token;}[WebMethod]public bool KeepToken(string tokenID){ var token = Domain.SSO.Entity.SSOToken.SSOTokenList.Find(m => m.ID == tokenID); if (token == null) return false; if (token.IsTimeOut()) return false; token.AuthTime = DateTime.Now; return true;}ValidateToken用来验证TokenID的合法性，KeepToken用来保持Token不会过期。SSO-Client通过调用Validate验证Token，并得到当前的登录用户信息。接下来看看SSO-Client的实现。SSO-ClientSSO-Client作为受信系统来存在的，它自己没有认证系统，只能通过SSO-Server来完成用户身份认证的工作。当用户请求SSO-Client的受保护资源时，SSO-Client会首先是否有TokenID，如果存在TokenID，则调用SSO-Server的WebService来验证这个TokenID是否合法；验证成功以后将会返回SSOToken的实例，里面包含已登录的用户信息。具体代码如下：if (!string.IsNullOrEmpty(tokenID)){ AuthTokenService.AuthTokenServiceSoapClient client = new AuthTokenService.AuthTokenServiceSoapClient(); var token = client.ValidateToken(tokenID); if (token != null) { this.lblMessage.Text = "登录成功，登录用户：" + token.User.UserName + "<a href="http://sso-server.com/logout.aspx?returnUrl=" + Server.UrlEncode("http://sso-client.com") + "">退出</a>"; } else { Response.Redirect("http://sso-server.com/sso.aspx?returnUrl=" + Server.UrlEncode("http://sso-client.com/default.aspx")); }}else{ Response.Redirect("http://sso-server.com/sso.aspx?returnUrl=" + Server.UrlEncode("http://sso-client.com/default.aspx"));}源代码文章中已经介绍了我的具体思路和一些实现，如果你仍然感兴趣，可以下载我的代码>>Demo.SSO源代码的部署：1. 在IIS中创建两个站点，分别绑定到SSO-Server和SSO-Client，它们绑定的域名分别是sso-server.com和sso-client.com2. 在hosts文件中添加两行映射，将sso-server.com和sso-client.com映射到127.0.0.1，确保可以访问3.访问sso-client.com，这个时候页面将跳转到sso-server.com的登录页面，用户名、密码随便输入，然后点击登录即可

SSO是Single Sign On的缩写，OAuth是Open Authority的缩写，这两者都是使用令牌的方式来代替用户密码访问应用。流程上来说他们非常相似，但概念上又十分不同。 以上两者，你在业务系统中都没有账号和密码，账号密码是存放在登录中心或微信服务器中的，这就是所谓的使用令牌代替账号密码访问应用。 两者有很多相似之处，下面我们来解释一下这个过程。先来讲解SSO，通过SSO对比OAuth2.0，才比较好理解OAuth2.0的原理。SSO的实现有很多框架，比如CAS框架，以下是CAS框架的官方流程图。 上面的流程大概为： OAuth2.0有多种模式，这里讲的是OAuth2.0授权码模式，OAuth2.0的流程跟SSO差不多 以上，就是我的SSO和OAuth2.0的理解。

首先需要明确的是：密码代填不是单点登录。例如 公司A 目前想实现单点登录，但是应用没有标准接口，也没有相应的开发人员，只能通过密码代填的方式来实现。需要注意的是，密码代填可能需要知道用户的账户密码进行传输。所以还是建议公司里应该试用基于协议的单点登录。目前市面上玉符科技专注于做单点登录，对于有些公司不得不通过密码代填的形式来实现单点登录的话，玉符可以确定的是他们所有传输都是通过https发生的，并且专门开发了非常安全的密钥管理机制KMS，经过多层加密，确保密码不会被窃取。以上。希望采纳

单点登录原理是让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。用户第一次访问应用系统的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份校验，如果通过校验，应该返回给用户一个认证的凭据－－ticket。用户再访问别的应用的时候，就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行校验，检查ticket的合法性。如果通过校验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。扩展资料优点：1）提高用户的效率。用户不再被多次登录困扰，也不需要记住多个 ID 和密码。另外，用户忘记密码并求助于支持人员的情况也会减少。2）提高开发人员的效率。SSO 为开发人员提供了一个通用的身份验证框架。实际上，如果 SSO 机制是独立的，那么开发人员就完全不需要为身份验证操心。他们可以假设，只要对应用程序的请求附带一个用户名，身份验证就已经完成了。3）简化管理。如果应用程序加入了单点登录协议，管理用户帐号的负担就会减轻。简化的程度取决于应用程序，因为 SSO 只处理身份验证。所以，应用程序可能仍然需要设置用户的属性（比如访问特权）。

就是点一下就登陆了···

单点登录是指在多个业务应用系统中，用户只需要登陆一次，就可以访问所有有权限的业务应用系统。在企业内部使用单点登录还是挺常见的，记录一下单点登录是什么主要是发现Oracle EBS也能单点登录，抽空特意了解了一下Oracle EBS单点登录的机制。 官方文档见 UG EBS的单点登录是需要依靠Oracle Access Manage和Oracle Directory Services，启用SSO之后，EBS会将登录的功能委派给Oracle Access Manger。 从实现原理的角度看，EBS的单点登录主要是依靠cookie实现。EBS会要求需要使用相同的域名来实现单点登录 打开EBS的网址后，如果EBS没有登录的话(判断EBS的cookie是否还存在且有效)就会重定向到OAM的网址去做登录 如果OAM已经登录了(判断OAM的cookie是否存在且有效)，就会重定向回EBS(返回到ebs的url中会包含用户信息，EBS会根据OAM的登录结果产生EBS的cookie)，这时EBS就会自动登录 如果OAM还没有登录，用户会在OAM的网站登录，成功登录后(OAM会创建一个cookie)，之后会重新回到EBS的界面，这时EBS就会自动登录了。 基本工作逻辑见下图 PS: Oracle Directory Services主要是用来存储用户名和密码信息以及映射到EBS的用户名 以上是基于标准模块的功能原理配置，如果要使用其他第三方SSO登录的软件的话，原理和上面的类似，都需要启用Oracle Access Manage和Oracle Directory Services。 只是OAM可以把登录的权限在委派给第三方的SSO软件 单点登出:也就是用户在EBS上面注销后应该一并注销单点登录认证，这需要在Access Gate做一些特殊处理清理一些cookies EBS实施单点登录时的一些特殊考量点： CAS是一个单点登录的协议，详细逻辑见 官网 。 从实现的角度感觉也还是用了session的功能。当第一次登陆SSO系统的时候，就会生成一个ticket，然后存放到了服务器，同时会分配给ticket给应用系统。之后应用系统访问SSO系统的时候就会带上ticket，SSO系统验证ticket来判断用户时候有效。

1. 前言 技术这东西吧，看别人写的好像很简单似的，到自己去写的时候就各种问题，“一看就会，一做就错”。网上关于实现SSO的文章一大堆，但是当你真的照着写的时候就会发现根本不是那么回事儿，简直让人抓狂，尤其是对于我这样的菜鸟。几经曲折，终于搞定了，决定记录下来，以便后续查看。先来看一下效果 2. 准备 2.1. 单点登录 最常见的例子是，我们打开淘宝APP，首页就会有天猫、聚划算等服务的链接，当你点击以后就直接跳过去了，并没有让你再登录一次 下面这个图是我再网上找的，我觉得画得比较明白： 可惜有点儿不清晰，于是我又画了个简版的： 重要的是理解： 2.2. OAuth2 推荐以下几篇博客 《 OAuth 2.0 》 《 Spring Security对OAuth2的支持 》 3. 利用OAuth2实现单点登录 接下来，只讲跟本例相关的一些配置，不讲原理，不讲为什么 众所周知，在OAuth2在有授权服务器、资源服务器、客户端这样几个角色，当我们用它来实现SSO的时候是不需要资源服务器这个角色的，有授权服务器和客户端就够了。 授权服务器当然是用来做认证的，客户端就是各个应用系统，我们只需要登录成功后拿到用户信息以及用户所拥有的权限即可 之前我一直认为把那些需要权限控制的资源放到资源服务器里保护起来就可以实现权限控制，其实是我想错了，权限控制还得通过Spring Security或者自定义拦截器来做 3.1. Spring Security 、OAuth2、JWT、SSO 在本例中，一定要分清楚这几个的作用 首先，SSO是一种思想，或者说是一种解决方案，是抽象的，我们要做的就是按照它的这种思想去实现它 其次，OAuth2是用来允许用户授权第三方应用访问他在另一个服务器上的资源的一种协议，它不是用来做单点登录的，但我们可以利用它来实现单点登录。在本例实现SSO的过程中，受保护的资源就是用户的信息（包括，用户的基本信息，以及用户所具有的权限），而我们想要访问这这一资源就需要用户登录并授权，OAuth2服务端负责令牌的发放等操作，这令牌的生成我们采用JWT，也就是说JWT是用来承载用户的Access_Token的 最后，Spring Security是用于安全访问的，这里我们我们用来做访问权限控制 4. 认证服务器配置 4.1. Maven依赖 这里面最重要的依赖是：spring-security-oauth2-autoconfigure 4.2. application.yml 4.3. AuthorizationServerConfig（重要） 说明： 4.4. WebSecurityConfig（重要） 4.5. 自定义登录页面（一般来讲都是要自定义的） 自定义登录页面的时候，只需要准备一个登录页面，然后写个Controller令其可以访问到即可，登录页面表单提交的时候method一定要是post，最重要的时候action要跟访问登录页面的url一样 千万记住了，访问登录页面的时候是GET请求，表单提交的时候是POST请求，其它的就不用管了 4.6. 定义客户端 4.7. 加载用户 登录账户 加载登录账户 4.8. 验证 当我们看到这个界面的时候，表示认证服务器配置完成　　 5. 两个客户端 5.1. Maven依赖 5.2. application.yml 这里context-path不要设成/，不然重定向获取code的时候回被拦截 5.3. WebSecurityConfig 说明： 5.4. MemberController 5.5. Order项目跟它是一样的 5.6. 关于退出 退出就是清空用于与SSO客户端建立的所有的会话，简单的来说就是使所有端点的Session失效，如果想做得更好的话可以令Token失效，但是由于我们用的JWT，故而撤销Token就不是那么容易，关于这一点，在官网上也有提到： 本例中采用的方式是在退出的时候先退出业务服务器，成功以后再回调认证服务器，但是这样有一个问题，就是需要主动依次调用各个业务服务器的logout 6. 工程结构 附上源码： https://github.com/chengjiansheng/cjs-oauth2-sso-demo.git 7. 演示 8. 参考 https://www.cnblogs.com/cjsblog/p/9174797.html https://www.cnblogs.com/cjsblog/p/9184173.html https://www.cnblogs.com/cjsblog/p/9230990.html https://www.cnblogs.com/cjsblog/p/9277677.html https://blog.csdn.net/fooelliot/article/details/83617941 http://blog.leapoahead.com/2015/09/07/user-authentication-with-jwt/ https://www.cnblogs.com/lihaoyang/p/8581077.html https://www.cnblogs.com/charlypage/p/9383420.html http://www.360doc.com/content/18/0306/17/16915_734789216.shtml https://blog.csdn.net/chenjianandiyi/article/details/78604376 https://www.baeldung.com/spring-security-oauth-jwt https://www.baeldung.com/spring-security-oauth-revoke-tokens https://www.reinforce.cn/t/630.html 9. 文档 https://projects.spring.io/spring-security-oauth/docs/oauth2.html https://docs.spring.io/spring-security-oauth2-boot/docs/2.1.3.RELEASE/reference/htmlsingle/ https://docs.spring.io/spring-security-oauth2-boot/docs/2.1.3.RELEASE/ https://docs.spring.io/spring-security-oauth2-boot/docs/ https://docs.spring.io/spring-boot/docs/2.1.3.RELEASE/ https://docs.spring.io/spring-boot/docs/ https://docs.spring.io/spring-framework/docs/ https://docs.spring.io/spring-framework/docs/5.1.4.RELEASE/ https://spring.io/guides/tutorials/spring-boot-oauth2/ https://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#core-services-password-encoding https://spring.io/projects/spring-cloud-security https://cloud.spring.io/spring-cloud-security/single/spring-cloud-security.html https://docs.spring.io/spring-session/docs/current/reference/html5/guides/java-security.html https://docs.spring.io/spring-session/docs/current/reference/html5/guides/boot-redis.html#boot-spring-configuration 原文链接：https://www.cnblogs.com/cjsblog/p/10548022.html

单点登录（SSO）是指只需要登录一次就可以访问所有相互信任的应用系统。根本要解决的是问题是存储信任和验证信任的问题。 为了更好理解单点登录的场景，以下以生活场景为例： 1. 小明进公司大门，看门大爷问小明要公司的一卡通，小明没有一卡通，查了查电话本，找到了人力部门的电话； 2. 看门大爷把人力部门电话给了小明； 3. 小明给人力部门电话打了过去； 4. 人力部门接了电话； 5. 小明报上了自己的大名，手机号，哪个部门等等信息； 6. 人力小姐姐去系统里面查了查，还真有小明这个人，于是就给了小明一个一卡通； 7. 然后小明又拿着这个一卡通给老大爷一看； 8. 老大爷还得再次确认一下这个一卡通是不是真的，老大爷又去跟人力确认； 9. 人力告诉老大爷，这个一卡通确实有效； 10. 老大爷把小明放进去了； 如果理解了小明持一卡通进入公司大门的场景，那么接下来就可以对照理解单点登录系统：1. 【客户端】发起请求，访问www.123.com，经过一个过滤器（CAS提供），判断用户是否登录过。如果没登录重定向到【认证中心】； 2. 【认证中心】给【客户端】返回了重定向地址：www.cas.123.com； 3. 【客户端】重定向到www.cas.123.com； 4. 【认证中心】返回了登录页面； 5. 用户输入用户名、密码； 6. 【认证中心】验证用户名、密码真实性。真实有效后，提供了一个ticket； 7. 【客户端】又拿着ticket去www.123.com请求； 8. 【服务端】拿着刚才用户提供过来的ticket去认证中心验证真实性； 9. 【认证中心】确认ticket真实有效； 10. 【服务端】返回相关资源，【客户端】展示相关资源。 当用户在访问其他业务系统时候，其他业务系统都会去【认证中心】验证用户携带的这个ticket，认证通过后即可直接访问其他业务系统，无需再次登录。

单点登录可以做到在不记录用户密码的情况下，实现不同系统之间的资源共享，自动登录不安全，单点登录，一处登录，处处都可用，不用做多余的登录操作

　　单点登录(Single Sign On)，简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统　　1.以Cookie作为凭证媒介　　最简单的单点登录实现方式，是使用cookie作为媒介，存放用户凭证。　　2.通过JSONP实现　　对于跨域问百题，可以使用JSONP实现。　　3.通过页面重定向的方式　　最后一种介绍的方式，是通过父应用和子应用来度回重定向中进行通信，实现信息的安全传版递。

sso单点登录原理是当用户在身份认证服务器上登录一次以后，即可获得访问单点登录系统中其他关联系统和应用软件的权限，同时这种实现是不需要管理员对用户的登录状态或其他信息进行修改。单点登录系统基于一种安全的通信协议，该协议通过多个系统之间的用户身份信息的交换来实现单点登录。使用单点登录系统时，用户只需要登录一次，就可以访问多个系统，不需要记忆多个口令密码。单点登录使用户可以快速访问网络，从而提高工作效率，同时也能帮助提高系统的安全性。扩展资料要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。另外：1、单一的用户信息数据库并不是必须的，有许多系统不能将所有的用户信息都集中存储，应该允许用户信息放置在不同的存储中，事实上，只要统一认证系统，统一ticket的产生和校验，无论用户信息存储在什么地方，都能实现单点登录。2、统一的认证系统并不是说只有单个的认证服务器当用户在访问应用系统1时，由第一个认证服务器进行认证后，得到由此服务器产生的ticket。当他访问应用系统2的时候，认证服务器2能够识别此ticket是由第一个服务器产生的，通过认证服务器之间标准的通讯协议（例如SAML）来交换认证信息，仍然能够完成SSO的功能。

但随着企业的发展，用到的系统随之增多，用户在操作不同的系统时，需要多次登录，而且每个系统的账号都不一样，这对于用户来说，很不方便。于是，就想到是不是可以在一个系统登录，其他系统就不用登录了呢？这就是单点登录要解决的问题。比如 淘宝，支付宝，天猫商城等都使用单点登录，同一个账号可以登录多个系统。 单点登录英文全称Single Sign On，简称就是SSO。是比较流行的企业业务整合的解决方案之一。 SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。 基础模式 SSO 访问流程主要有以下步骤：登录后设置的 Cookie，之后每次访问时都会携带该 Cookie，从而让后台服务能识别当前登录用户。Cookie过期重新登录 如果是同域下系统登录，依旧可以使用此方式进行登录具体流程如下： 具体流程如下： 用户登出时要做的事情很简单： ST （ Service Ticket ）是通过 Http 传送的，因此网络中的其他人可以 Sniffer 到其他人的 Ticket 。 CAS 通过以下几方面来使 ST 变得更加安全（事实上都是可以配置的）： CAS 协议规定，无论 Service Ticket 验证是否成功， CAS Server 都会清除服务端缓存中的该Ticket ，从而可以确保一个 Service Ticket 不被使用两次。 2. ST 在一段时间内失效 CAS 规定 ST 只能存活一定的时间，然后 CAS Server 会让它失效。默认有效时间为 5 分钟。 3. ST 是基于随机数生成的 ST 必须足够随机，如果 ST 生成规则被猜出， Hacker 就等于绕过 CAS 认证，直接访问 对应的服务。

单点登录在大型网站里使用得非常频繁，例如，阿里旗下有淘宝、天猫、支付宝,阿里巴巴，阿里妈妈，阿里妹妹等网站

JWT全称“JSON Web Token”，是基于JSON的用户身份认证的令牌。可跨域身份认证，所以JWT很适合做分布式的鉴权，单点登录（SingleSign,SSO）。 jwt有三部分组成用符号"."隔开， HEADER：token头，描述token是什么类型，加密方式是什么，把json内容转为base64 PAYLOAD:内容，是暴露出来的信息，不可存敏感信息,把json内容转为base64 SIGNATURE:签名，按token头的加密方式把HEADER和PAYLOAD的信息加密生成签名，下面是官网上面的介绍，地址： https://jwt.io/ jwt的token是不可以篡改的，虽然前两部分的内容可以base64解码之后就能看到明文，但由于第三部分签名是把前两部分内容用一个密钥加密的，验证的时候也是把前两部分内容再次加密和原来签名对比是否一致，若内容被篡改了，则两次签名不一致校验不通过。 问题一：同一个公司的系统 ，不如果每个系统都有一套自己的用户名密码，那用户记 得头都大了啊。所以这时产生了一个鉴权中心，全部系统用同一套用户信息，同一个地方登录。 问题二：用同一套用户信息可以了，但如果进每个系统都要输一次账户密码登录还是很麻烦的。所以这里还要一处登录 ，处处登录，登录了其中一个系统，进入其它系统的时候不需要登录 效果如下图所示 用户在sso中心登录后的token在站点A，站点B都能使用，并且站点A，站点B和sso中心不需要通讯也能自己鉴别token是否是有效的。 怎么做到站点和sso串联呢？具体的流程是用户打开站点A，发现未登录 ，那站点A会跳转到sso中心登录并且把自己的url带上，sso中心登录成功后，跳转回站点带过来的url并把token也带上。 那站点A登录成功了，站点B怎么共享这个Token呢，做法是，sso中心登录成功的时候同时存一份Token到cookie(或localstorage等地方)，当用户进入站点B的时候，发现没登录，跳转到sso中心带上自己的url，sso中心发现cookie有token了，直接跳转回站点B的url并把token带上，这样站点B就能实现token共享和自动登录了。 新建一个AuthenticationCenter项目 新建一个AuthenticatinController控制器 Login的view视图 其它相关类 上面sso的登录功能就完成了，打开Login页面就能获取到Token了。 新建一个站点A 修改startup.cs文件，在ConfigureServices方法里加上 在Configure方法里加上 新建一个UserController 其它相关类 密钥要和sso中心的保持一致，上面的5000端口是sso的端口，27271端口是站点端口。

您好，想要知道他单点登录的一些原理的话，那么其实是需要学习的。或者也可以问一下吧，不知道你能不能够理解。

通过 JWT 配合 Spring Security OAuth2 使用的方式，可以避免 每次请求 都 远程调度 认证授权服务。 资源服务器 只需要从 授权服务器 验证一次，返回 JWT。返回的 JWT 包含了 用户 的所有信息，包括 权限信息 。 1. 什么是JWT JSON Web Token（JWT）是一种开放的标准（RFC 7519），JWT 定义了一种 紧凑 且 自包含 的标准，旨在将各个主体的信息包装为 JSON 对象。 主体信息 是通过 数字签名 进行 加密 和 验证 的。经常使用 HMAC 算法或 RSA（ 公钥 / 私钥 的 非对称性加密 ）算法对 JWT 进行签名， 安全性很高 。 2. JWT的结构 JWT 的结构由三部分组成：Header（头）、Payload（有效负荷）和 Signature（签名）。因此 JWT 通常的格式是 xxxxx.yyyyy.zzzzz。 2.1. Header Header 通常是由 两部分 组成：令牌的 类型 （即 JWT）和使用的 算法类型 ，如 HMAC、SHA256 和 RSA。例如: 将 Header 用 Base64 编码作为 JWT 的 第一部分 ，不建议在 JWT 的 Header 中放置 敏感信息 。 2.2. Payload 下面是 Payload 部分的一个示例： 将 Payload 用 Base64 编码作为 JWT 的 第二部分 ，不建议在 JWT 的 Payload 中放置 敏感信息 。 2.3. Signature 要创建签名部分，需要利用 秘钥 对 Base64 编码后的 Header 和 Payload 进行 加密 ，加密算法的公式如下： 签名 可以用于验证 消息 在 传递过程 中有没有被更改。对于使用 私钥签名 的 token，它还可以验证 JWT 的 发送方 是否为它所称的 发送方 。 3. JWT的工作方式 客户端 获取 JWT 后，对于以后的 每次请求 ，都不需要再通过 授权服务 来判断该请求的 用户 以及该 用户的权限 。在微服务系统中，可以利用 JWT 实现 单点登录 。认证流程图如下： 4. 案例工程结构 工程原理示意图如下: 5. 构建auth-service授权服务 UserServiceDetail.java UserRepository.java 实体类 User 和上一篇文章的内容一样，需要实现 UserDetails 接口，实体类 Role 需要实现 GrantedAuthority 接口。 User.java Role.java jks 文件的生成需要使用 Java keytool 工具，保证 Java 环境变量没问题，输入命令如下： 其中，-alias 选项为 别名 ，-keyalg 为 加密算法 ，-keypass 和 -storepass 为 密码选项 ，-keystore 为 jks 的 文件名称 ，-validity 为配置 jks 文件 过期时间 （单位：天）。 生成的 jks 文件作为 私钥 ，只允许 授权服务 所持有，用作 加密生成 JWT。把生成的 jks 文件放到 auth-service 模块的 src/main/resource 目录下即可。 对于 user-service 这样的 资源服务 ，需要使用 jks 的 公钥 对 JWT 进行 解密 。获取 jks 文件的 公钥 的命令如下： 这个命令要求安装 openSSL 下载地址，然后手动把安装的 openssl.exe 所在目录配置到 环境变量 。 输入密码 fzp123 后，显示的信息很多，只需要提取 PUBLIC KEY，即如下所示： 新建一个 public.cert 文件，将上面的 公钥信息 复制到 public.cert 文件中并保存。并将文件放到 user-service 等 资源服务 的 src/main/resources 目录下。至此 auth-service 搭建完毕。 maven 在项目编译时，可能会将 jks 文件 编译 ，导致 jks 文件 乱码 ，最后不可用。需要在 pom.xml 文件中添加以下内容： 6. 构建user-service资源服务 注入 JwtTokenStore 类型的 Bean，同时初始化 JWT 转换器 JwtAccessTokenConverter，设置用于解密 JWT 的 公钥 。 配置 资源服务 的认证管理，除了 注册 和 登录 的接口之外，其他的接口都需要 认证 。 新建一个配置类 GlobalMethodSecurityConfig，通过 @EnableGlobalMethodSecurity 注解开启 方法级别 的 安全验证 。 拷贝 auth-service 模块的 User、Role 和 UserRepository 三个类到本模块。在 Service 层的 UserService 编写一个 插入用户 的方法，代码如下： 配置用于用户密码 加密 的工具类 BPwdEncoderUtil： 实现一个 用户注册 的 API 接口 /user/register，代码如下： 在 Service 层的 UserServiceDetail 中添加一个 login() 方法，代码如下： AuthServiceClient 作为 Feign Client，通过向 auth-service 服务接口 /oauth/token 远程调用获取 JWT。在请求 /oauth/token 的 API 接口中，需要在 请求头 传入 Authorization 信息， 认证类型 ( grant_type )、用户名 ( username ) 和 密码 ( password )，代码如下： 其中，AuthServiceHystrix 为 AuthServiceClient 的 熔断器 ，代码如下： JWT 包含了 access_token、token_type 和 refresh_token 等信息，代码如下： UserLoginDTO 包含了一个 User 和一个 JWT 成员属性，用于返回数据的实体： 登录异常类 UserLoginException 全局异常处理 切面类 ExceptionHandle 在 Web 层的 UserController 类中新增一个登录的 API 接口 /user/login 如下： 依次启动 eureka-service，auth-service 和 user-service 三个服务。 7. 使用Postman测试 因为没有权限，访问被拒绝。在数据库手动添加 ROLE_ADMIN 权限，并与该用户关联。重新登录并获取 JWT，再次请求 /user/foo 接口。 在本案例中，用户通过 登录接口 来获取 授权服务 加密后的 JWT。用户成功获取 JWT 后，在以后每次访问 资源服务 的请求中，都需要携带上 JWT。 资源服务 通过 公钥解密 JWT， 解密成功 后可以获取 用户信息 和 权限信息 ，从而判断该 JWT 所对应的 用户 是谁，具有什么 权限 。 获取一次 Token，多次使用， 资源服务 不再每次访问 授权服务 该 Token 所对应的 用户信息 和用户的 权限信息 。 一旦 用户信息 或者 权限信息 发生了改变，Token 中存储的相关信息并 没有改变 ，需要 重新登录 获取新的 Token。就算重新获取了 Token，如果原来的 Token 没有过期，仍然是可以使用的。一种改进方式是在登录成功后，将获取的 Token 缓存 在 网关上 。如果用户的 权限更改 ，将 网关 上缓存的 Token 删除 。当请求经过 网关 ，判断请求的 Token 在 缓存 中是否存在，如果缓存中不存在该 Token，则提示用户 重新登录 。