【精选】SSO单点登录和OAuth2.0的区别和理解_sso oauth

二、SSO

两者有很多相似之处，下面我们来解释一下这个过程。先来讲解SSO，通过SSO对比OAuth2.0，才比较好理解OAuth2.0的原理。 SSO的实现有很多框架，比如CAS框架 ，以下是CAS框架的官方流程图。特别注意： SSO是一种思想，而CAS只是实现这种思想的一种框架而已

上面的流程大概为：

用户输入网址进入业务系统Protected App，系统发现用户未登录，将用户重定向到单点登录系统CAS Server，并带上自身地址service参数
用户浏览器重定向到单点登录系统，系统检查该用户是否登录，这是SSO(这里是CAS)系统的第一个接口，该接口如果用户未登录，则将用户重定向到登录界面，如果已登录，则设置全局session，并重定向到业务系统
用户填写密码后提交登录，注意此时的登录界面是SSO系统提供的，只有SSO系统保存了用户的密码，
SSO系统验证密码是否正确，若正确则重定向到业务系统，并带上SSO系统的签发的ticket
浏览器重定向到业务系统的登录接口，这个登录接口是不需要密码的，而是带上SSO的ticket，业务系统拿着ticket请求SSO系统，获取用户信息。并设置局部session，表示登录成功返回给浏览器sessionId(tomcat中叫JSESSIONID)
之后所有的交互用sessionId与业务系统交互即可

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

三、OAuth2.0

OAuth2.0有多种模式，这里讲的是OAuth2.0授权码模式，OAuth2.0的流程跟SSO差不多， 在OAuth2中，有授权服务器、资源服务器、客户端这样几个角色，当我们用它来实现SSO的时候是不需要资源服务器这个角色的，有授权服务器和客户端就够了 。授权服务器当然是用来做认证的，客户端就是各个应用系统，我们只需要登录成功后拿到用户信息以及用户所拥有的权限即可

用户在某网站上点击使用微信授权，这里的某网站就类似业务系统，微信授权服务器就类似单点登录系统
之后微信授权服务器返回一个确认授权页面，类似登录界面，这个页面当然是微信的而不是业务系统的
用户确认授权，类似填写了账号和密码，提交后微信鉴权并返回一个ticket，并重定向业务系统。
业务系统带上ticket访问微信服务器，微信服务器返回正式的token，业务系统就可以使用token获取用户信息了

简介一下OAuth2.0的四种模式：

授权码（authorization-code）

授权码（authorization code）方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌。这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。

隐藏式（implicit）

有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）“隐藏式”（implicit）

密码式（password）

如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。

客户端凭证（client credentials）

最后一种方式是凭证式（client credentials），适用于没有前端的命令行应用，即在命令行下请求令牌。

详细的OAuth2.0讲解

四、说一下几个名词的区别（ Spring Security 、Shiro、OAuth2、JWT、SSO）

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

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

最后， Spring Security、Shiro是用于安全访问的，用来做访问权限控制，都是一个用Java写的框架

参考文章
 参考文章

一、概述SSO是Single Sign On的缩写，OAuth是Open Authority的缩写，这两者都是使用令牌的方式来代替用户密码访问应用。流程上来说他们非常相似，但概念上又十分不同。SSO大家应该比较熟悉，它将登录认证和业务系统分离，使用独立的登录中心，实现了在登录中心登录后，所有相关的业务系统都能免登录访问资源。OAuth2.0原理可能比较陌生，但平时用的却很多，比如访问某网站想留言又不想注册时使用了微信授权。以上两者，你在业务系统中都没有账号和密码，账号密码是存放在登录中心或微信服务器中的，

spring security 基于 oauth 2.0 实现 sso 单点登录 Demo 使用 spring security 基于 oauth 2.0 实现 sso 单点登录 Demo spring boot + spring security + spring security oauth

代码怎么写，原理等请参考阮一峰博客四种模式都讲的非常清楚，这里我就我遇到的问题做个记录什么用户存入数据库，客户端信息持久化，access_token存入redis等问题网上都可以搜到我所遇到的问题在获取code的时候，也就是 / oauth /authorize 接口（在AuthorizationEndpoint类中） User must be authenticated with Spring Security before authorization can be completed. 这是没有登

参考大神的博客 https://www.springcloud.cc/spring-security-zhcn.html https://blog.csdn.net/larger5/article/details/81063438 代码主要是从这整过来的 https://blog.csdn.net/zzxzzxhao/article/details/83412648 https://www.cnb...

分布式环境：多个Tomcat，Nginx做负载均衡，无法实现session共享 ip轮询（session黏贴）：每次请求，固定机制，都分发到第一台服务器，存储session的服务器一旦挂掉，其他服务器无法使用。 session复制：各个节点都复制session，但是session比较重，一旦请求早于复制过程，就会出现登录异常问题。 session集中存储：使用三方的redis。基于无状态token方式：token保存用户所有信息，返回到客户

简介和区别 SSO , single sign on, 单点登录 。 sso 多用于多个应用之间的切换，例如百度论坛、百度知道、百度云、百度文库等，在其中一个系统中登录，切换到另一个系统的时候，不必再次输入用户名密码。 oauth2.0 ，开放授权，不兼容 oauth 1.0.允许第三方应用代表用户获得访问权限。可以作为web应用、桌面应用和手机等设备提供专门的认证流程。例如，用qq账号登录豆瓣、美团、大众点评；用支付宝账号登录淘宝、天猫等。区别： sso 和 oauth2.0 在应用场景上的区别在于， SSO 是为了解决一个用

OAuth2.0 与 SSO 比较_咖啡男孩之SRE之路-CSDN博客_ oauth2.0 与 sso OAuth 是Open Authority的缩写，是令牌代替用户密码访问应用的又一标准，前面一期介绍过 SSO 单点登录 （SpringBoot模拟 单点登录 ），也是令牌登陆的一种方式。 OAuth2.0 最典型的授权码认证方式：资源服务器和鉴权服务器都是属于资源所有方，也就是最终的服务提供方，第三接入方需要先与鉴权服务器申请合作获取客户编码。对于资源服务器来说，需要做的是 1 accessToken和cl

网上有很多Spring Security和 oauth 2的介绍，但是对于初学者来说，上手比较复杂，本篇从原理上梳理一下两者之间的联系和区别 1. 什么是Spring Security 参见【Spring Security】基本功能介绍 spring security 的核心功能主要包括：认证（你是谁）通过注解 @EnableWebSecurity开启简单来说，就是需要登录，你需要输入用户名和密码，才能访问某个url。授权（你能干什么）不需要通过指定的开关开启，而是通 单点登录 （ SSO ）和 OAuth 2.0都是用于认证和授权的协议，但它们的目的和使用场景不同。 SSO 是一种身份验证技术，它允许用户一次登录，然后在不同的应用程序之间无需再次输入登录凭证即可访问这些应用程序。而 OAuth 2.0是一种授权框架，允许用户授权第三方应用程序访问其受保护的资源（例如，用户的照片或联系人列表），而无需与第三方共享其登录凭证。在某些情况下， SSO 和 OAuth 2.0可以一起使用，以提供更安全、更便捷的用户体验。例如，在企业环境中，员工可能需要访问多个应用程序，而 SSO 可以帮助他们避免重复输入凭证。但是，企业应用程序可能需要访问员工的受保护资源，如日历、联系人、文件等，这就需要使用 OAuth 2.0进行授权。在这种情况下，可以使用以下步骤来将 SSO 和 OAuth 2.0结合起来使用： 1. 用户登录到 SSO 系统，获取访问令牌。 2. 用户使用访问令牌访问企业应用程序。 3. 应用程序检查访问令牌，并使用 OAuth 2.0协议向 SSO 系统请求访问受保护资源的授权。 4. SSO 系统验证用户的身份，并提示用户是否授权企业应用程序访问其受保护资源。 5. 如果用户授权， SSO 系统将向企业应用程序颁发一个访问令牌，该令牌可用于访问受保护资源。通过将 SSO 和 OAuth 2.0结合使用，企业可以为员工提供一种方便的身份验证机制，并确保只有授权的应用程序可以访问受保护资源。