SSO单点登录和OAuth2.0区别

一、概述

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

二、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的时候是不需要资源服务器这个角色的,有授权服务器和客户端就够了。授权服务器当然是用来做认证的,客户端就是各个应用系统,我们只需要登录成功后拿到用户信息以及用户所拥有的权限即可

插播一条,如果你近期准备面试跳槽,建议在ddkk.com在线刷题,涵盖 1万+ 道 Java 面试题,几乎覆盖了所有主流技术面试题,还有市面上最全的技术栈500套,精品系列教程,免费提供。

  • 用户在某网站上点击使用微信授权,这里的某网站就类似业务系统,微信授权服务器就类似单点登录系统

  • 之后微信授权服务器返回一个确认授权页面,类似登录界面,这个页面当然是微信的而不是业务系统的

  • 用户确认授权,类似填写了账号和密码,提交后微信鉴权并返回一个ticket,并重定向业务系统。

  • 业务系统带上ticket访问微信服务器,微信服务器返回正式的token,业务系统就可以使用token获取用户信息了

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

1、 授权码(authorization-code);

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

1、 隐藏式(implicit);

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

1、 密码式(password);

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

1、 客户端凭证(clientcredentials);

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

简单流程

图片

详细的OAuth2.0讲解

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

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

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

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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
好的,我会为您解答。在上一篇博客中,我们已经介绍了OAuth2.0的登录流程以及登录的实现方式。接下来,我将为您介绍OAuth2.0的登出流程。 在OAuth2.0的登出流程中,与登录流程类似,也需要涉及到三个角色:用户、客户端和认证服务器。下面是OAuth2.0的登出流程: 1. 用户在客户端应用程序中发起登出请求,客户端应用程序将请求转发给认证服务器。 2. 认证服务器接收到登出请求后,会将用户的会话标识从认证服务器的存储中删除,并向客户端应用程序发回响应,告诉客户端应用程序用户已经登出。 3. 客户端应用程序接收到响应后,会清除本地存储的用户会话信息,并将用户重定向到认证服务器的登出页面。 4. 当用户在认证服务器登出页面上点击确认登出后,认证服务器会将用户重定向到客户端应用程序的登出回调URL,并在URL中包含一个参数,表示用户已经登出。 5. 客户端应用程序接收到认证服务器的登出回调请求后,会清除本地存储的用户会话信息,并重定向用户到应用程序的登录页面。 需要注意的是,OAuth2.0的登出流程中并没有提供点登出的实现方式,因为OAuth2.0本身并不支持点登出。如果需要实现点登出,可以借助于其他的技术手段,比如使用Redis等缓存技术来实现点登出。 好的,以上就是OAuth2.0的登出流程。希望对您有所帮助。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值