sso单点登录原理

sso单点登录原理是当用户在身份认证服务器上登录一次以后，即可获得访问单点登录系统中其他关联系统和应用软件的权限，同时这种实现是不需要管理员对用户的登录状态或其他信息进行修改。

单点登录系统基于一种安全的通信协议，该协议通过多个系统之间的用户身份信息的交换来实现单点登录。

使用单点登录系统时，用户只需要登录一次，就可以访问多个系统，不需要记忆多个口令密码。单点登录使用户可以快速访问网络，从而提高工作效率，同时也能帮助提高系统的安全性。

扩展资料

要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。

另外：

1、单一的用户信息数据库并不是必须的，有许多系统不能将所有的用户信息都集中存储，应该允许用户信息放置在不同的存储中，事实上，只要统一认证系统，统一ticket的产生和校验，无论用户信息存储在什么地方，都能实现单点登录。

2、统一的认证系统并不是说只有单个的认证服务器

当用户在访问应用系统1时，由第一个认证服务器进行认证后，得到由此服务器产生的ticket。当他访问应用系统2的时候，认证服务器2能够识别此ticket是由第一个服务器产生的，通过认证服务器之间标准的通讯协议（例如SAML）来交换认证信息，仍然能够完成SSO的功能。

1 前言

技术这东西吧，看别人写的好像很简单似的，到自己去写的时候就各种问题，“一看就会，一做就错”。网上关于实现SSO的文章一大堆，但是当你真的照着写的时候就会发现根本不是那么回事儿，简直让人抓狂，尤其是对于我这样的菜鸟。几经曲折，终于搞定了，决定记录下来，以便后续查看。先来看一下效果

2 准备

21 单点登录

最常见的例子是，我们打开淘宝APP，首页就会有天猫、聚划算等服务的链接，当你点击以后就直接跳过去了，并没有让你再登录一次

下面这个图是我再网上找的，我觉得画得比较明白：

可惜有点儿不清晰，于是我又画了个简版的：

重要的是理解：

22 OAuth2

推荐以下几篇博客

《 OAuth 20 》

《 Spring Security对OAuth2的支持 》

3 利用OAuth2实现单点登录

接下来，只讲跟本例相关的一些配置，不讲原理，不讲为什么

众所周知，在OAuth2在有授权服务器、资源服务器、客户端这样几个角色，当我们用它来实现SSO的时候是不需要资源服务器这个角色的，有授权服务器和客户端就够了。

授权服务器当然是用来做认证的，客户端就是各个应用系统，我们只需要登录成功后拿到用户信息以及用户所拥有的权限即可

之前我一直认为把那些需要权限控制的资源放到资源服务器里保护起来就可以实现权限控制，其实是我想错了，权限控制还得通过Spring Security或者自定义拦截器来做

31 Spring Security 、OAuth2、JWT、SSO

在本例中，一定要分清楚这几个的作用

首先，SSO是一种思想，或者说是一种解决方案，是抽象的，我们要做的就是按照它的这种思想去实现它

其次，OAuth2是用来允许用户授权第三方应用访问他在另一个服务器上的资源的一种协议，它不是用来做单点登录的，但我们可以利用它来实现单点登录。在本例实现SSO的过程中，受保护的资源就是用户的信息（包括，用户的基本信息，以及用户所具有的权限），而我们想要访问这这一资源就需要用户登录并授权，OAuth2服务端负责令牌的发放等操作，这令牌的生成我们采用JWT，也就是说JWT是用来承载用户的Access_Token的

最后，Spring Security是用于安全访问的，这里我们我们用来做访问权限控制

4 认证服务器配置

41 Maven依赖

这里面最重要的依赖是：spring-security-oauth2-autoconfigure

42 applicationyml

43 AuthorizationServerConfig（重要）

说明：

44 WebSecurityConfig（重要）

45 自定义登录页面（一般来讲都是要自定义的）

自定义登录页面的时候，只需要准备一个登录页面，然后写个Controller令其可以访问到即可，登录页面表单提交的时候method一定要是post，最重要的时候action要跟访问登录页面的url一样

千万记住了，访问登录页面的时候是GET请求，表单提交的时候是POST请求，其它的就不用管了

46 定义客户端

47 加载用户

登录账户

加载登录账户

48 验证

当我们看到这个界面的时候，表示认证服务器配置完成　　

5 两个客户端

51 Maven依赖

52 applicationyml

这里context-path不要设成/，不然重定向获取code的时候回被拦截

53 WebSecurityConfig

说明：

54 MemberController

55 Order项目跟它是一样的

56 关于退出

退出就是清空用于与SSO客户端建立的所有的会话，简单的来说就是使所有端点的Session失效，如果想做得更好的话可以令Token失效，但是由于我们用的JWT，故而撤销Token就不是那么容易，关于这一点，在官网上也有提到：

本例中采用的方式是在退出的时候先退出业务服务器，成功以后再回调认证服务器，但是这样有一个问题，就是需要主动依次调用各个业务服务器的logout

6 工程结构

附上源码： https://githubcom/chengjiansheng/cjs-oauth2-sso-demogit

7 演示

8 参考

https://wwwcnblogscom/cjsblog/p/9174797html

https://wwwcnblogscom/cjsblog/p/9184173html

https://wwwcnblogscom/cjsblog/p/9230990html

https://wwwcnblogscom/cjsblog/p/9277677html

https://blogcsdnnet/fooelliot/article/details/83617941

http://blogleapoaheadcom/2015/09/07/user-authentication-with-jwt/

https://wwwcnblogscom/lihaoyang/p/8581077html

https://wwwcnblogscom/charlypage/p/9383420html

http://www360doccom/content/18/0306/17/16915_734789216shtml

https://blogcsdnnet/chenjianandiyi/article/details/78604376

https://wwwbaeldungcom/spring-security-oauth-jwt

https://wwwbaeldungcom/spring-security-oauth-revoke-tokens

https://wwwreinforcecn/t/630html

9 文档

https://projectsspringio/spring-security-oauth/docs/oauth2html

https://docsspringio/spring-security-oauth2-boot/docs/213RELEASE/reference/htmlsingle/

https://docsspringio/spring-security-oauth2-boot/docs/213RELEASE/

https://docsspringio/spring-security-oauth2-boot/docs/

https://docsspringio/spring-boot/docs/213RELEASE/

https://docsspringio/spring-boot/docs/

https://docsspringio/spring-framework/docs/

https://docsspringio/spring-framework/docs/514RELEASE/

https://springio/guides/tutorials/spring-boot-oauth2/

https://docsspringio/spring-security/site/docs/current/reference/htmlsingle/#core-services-password-encoding

https://springio/projects/spring-cloud-security

https://cloudspringio/spring-cloud-security/single/spring-cloud-securityhtml

https://docsspringio/spring-session/docs/current/reference/html5/guides/java-securityhtml

https://docsspringio/spring-session/docs/current/reference/html5/guides/boot-redishtml#boot-spring-configuration

原文链接：https://wwwcnblogscom/cjsblog/p/10548022html

按照我最近刚做过的demo，应该是先访问你工程的一个url，这时候cas服务器进行验证，如果之前登陆了，直接跳转，如果没登录，会跳转到cas服务器的登录页面，这时候它会自动保存你之前请求的url地址，你输入用户名密码验证成功之后自动跳过去，还需要单独设置么？

在介绍具体协议之前，有必要先说明“认证（Authentication）”和“授权（Authorization）”的区别。

也就是说，当用户登录应用系统时，系统需要先认证用户身份，然后依据用户身份再进行授权。认证与授权需要联合使用，才能让用户真正登入并使用应用系统。

Central Authentication Service简称CAS，是一种常见的B/S架构的SSO协议。和其他任何SSO协议一样，用户仅需登陆一次，访问其他应用则无需再次登陆。

顾名思义，CAS是一种仅用于Authentication的服务，它和OAuth/OIDC协议不一样，并不能作为一种Authorization的协议。

当前CAS协议包括CAS 10、CAS20、CAS30版本，这三个版本的认证流程基本类似。

CAS的认证流程通过包括几部分参与者:

认证流程大致为:

注: CAS 10是个非常简单粗陋的协议，在20、30版本中，Service Ticket的校验结果均为XML格式， 且引入了一种proxy模式（不在本文做深入讨论）。

CAS协议的详细标准定义，请参考：

https://apereogithubio/cas/62x/protocol/CAS-Protocol-Specificationhtml

谈到OAuth, 通常是指OAuth 20协议，它是一种Authorization协议并不是一种Authentication协议，虽然OAuth 2的流程中只描述了Authorization。但是在实际使用中，Authorization脱离Authentication并没有任何意义。

OAuth 20解决的主要场景是: 第三方应用如何被授权访问资源服务器。 整个流程参与者包括几个组成部分:

抽象的授权流程大致为:

假定一个在线音乐服务，用户zhangsan想通过某音视频播放软件来播放在线音乐, 但是在播放音乐之前，该音视频软件必须得通过YuFu（即玉符IDaaS）认证授权，得到zhangsan的同意之后才能访问在线音乐。

在这个场景中，zhangsan为Resource Owner, 在线音乐服务为Resource Server, Client为某音视频播放软件，YuFu作为Authorization Server。

上述是一个抽象的授权流程，而在具体实现中，在前三步中会有几个变种，即不同的授权模式，常见的授权模式包括:

可以发现在整个流程中，音视频播放器并不需要知道zhangsan的密码，只是需要得到zhangsan的授权就可以访问在线音乐， 而整个授权是由Authorization Server来负责。

本文并不会展开讨论Authorization Code模式，详细协议文档定义请参考：

https://toolsietforg/html/rfc6749

笔者意见：相比CAS协议，OAuth20不同的授权模式能够解决更多的场景，更安全、更流行，且通过PKCE模式能够实现移动端的单点登录，这个是其他SSO协议都不具备的 （PKCE模式

参考资料：

https://toolsietforg/html/rfc7636 ）。

OpenID Connect简称OIDC，是基于OAuth20扩展出来的一个协议。除了能够OAuth20中的Authorization场景，还额外定义了Authentication的场景，可以说OIDC协议是当今最流行的协议。

相比OAuth2，OIDC引入了id_token等和userinfo相关的概念：

可以说OIDC协议是目前最主流的SSO标准协议，且对开发者友好，实现起来比较简单。

详细协议标准定义参考：

https://openidnet/specs/openid-connect-core-1_0html

上面简单介绍了主流的几种SSO协议，本质上它们大同小异，都是基于中心信任的机制，服务提供者和身份提供者之间通过互信来交换用户信息，只是每个协议信息交换的细节不同，或者概念上有些不同。

最后，通过一个简单对比表格来总结本文重点内容：

​刚才突然想明白了单点登录的token为什么不需要针对每个用户都存一个session。

服务器这边准备一个密码字符串，各服务器保持字符串一样。

当用户登录一台服务器成功后，服务器将他的账号和密码字符串通过算法整合一下，形成一个新的字符串。通常这个算法会将密码字符串用哈希的方式来处理(即在新的字符串中不知道这个密码是多少)，但账号可以直接在新的字符串中拿到。

这样，服务器将这个新的字符串给用户(即保存在cookie中，或保存在storage中)。用户每次访问，都会带上这个字符串(类似jsessionid)。

服务器这边拿到用户带来的字符串，从中取出账号，将账号和服务器这边存的密码用相同算法整合，形成新的字符串，用这个字符串和用户带来的字符串比对，看是否相同，相同，即通过，不同，让用户去登录。