认识OAuth2.0

简介: OAuth2.0是开放授权标准,允许第三方应用在用户授权下安全访问资源,无需获取用户账号密码。包含授权码、简化、密码和客户端四种模式,广泛用于API授权与单点登录场景。

.什么是OAuth2.0
先说OAuth,OAuth是Open Authorization的简写。 OAuth协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAuth的授权不会使第三方触及到用户的帐号信息(如用户名与密码),即第三方无需使用用户的用户名与 密码就可以申请获得该用户资源的授权,因此OAuth是安全的。
OAuth2.0是OAuth协议的延续版本,但不向前兼容(即完全废止了OAuth1.0)。
2.OAuth2.0使用场景
假设,A网站是一个打印照片的网站,B网站是一个存储照片的网站,二者原本毫无关联。
如果一个用户想使用A网站打印自己存储在B网站的照片,那么A网站就需要使用B网站的照片资源才行。 按照传统的思考模式,我们需要A网站具有登录B网站的用户名和密码才行,但是有OAuth2后,只需要A网站获取到使用B网站照片资源的一个通行令牌即可!这个令牌无需具备操作B网站所有资源的权限,也无需永久有效,只要满足A网站打印照片需求即可。
这么听来,是不是有点像单点登录?千万不要混淆概念!单点登录是用户一次登录,自己可以操作其 他关联的服务资源。OAuth2则是用户给一个系统授权,可以直接操作其他系统资源的一种方式。
总结一句:SpringSecurity的OAuth2可以做服务之间资源共享,也可以实现单点登录!
3.OAuth2.0四种授权模式
针对上面的获取照片,我们结合下图进行详细展开

授权码模式
流程
说明:【A服务客户端】需要用到【B服务资源服务】中的资源
● 第一步:【A服务客户端】将用户自动导航到【B服务认证服务】,这一步用户需要提供一个回调地址,以备 【B服务认证服务】返回授权码使用。
● 第二步:用户点击授权按钮表示让【A服务客户端】使用【B服务资源服务】,这一步需要用户登录B服务,也就是说用户要事先具有B服务的使用权限。
● 第三步:【B服务认证服务】生成授权码,授权码将通过第一步提供的回调地址,返回给【A服务客户端】。 注意这个授权码并非通行【B服务资源服务】的通行凭证。
● 第四步:【A服务认证服务】携带上一步得到的授权码向【B服务认证服务】发送请求,获取通行凭证token。
● 第五步:【B服务认证服务】给【A服务认证服务】返回令牌token和更新令牌refresh token。
场景
授权码模式是OAuth2中最安全最完善的一种模式,应用场景最广泛,可以实现服务之间的调用,常见的微信,QQ等第三方登录也可采用这种方式实现。

简化模式
流程
说明:简化模式中没有【A服务认证服务】这一部分,全部有【A服务客户端】与B服务交互,整个过程不再有授权码,token直接暴露在浏览器。
● 第一步:【A服务客户端】将用户自动导航到【B服务认证服务】,这一步用户需要提供一个回调地址,以备【B服务认证服务】返回token使用,还会携带一个【A服务客户端】的状态标识state。
● 第二步:用户点击授权按钮表示让【A服务客户端】使用【B服务资源服务】,这一步需要用户登录B服务,也就是说用户要事先具有B服务的使用权限。
● 第三步:【B服务认证服务】生成通行令牌token,token将通过第一步提供的回调地址,返回给【A服务客户端】。
场景
适用于A服务没有服务器的情况。比如:纯手机小程序,JavaScript语言实现的网页插件等。

密码模式
流程
● 第一步:直接告诉【A服务客户端】自己的【B服务认证服务】的用户名和密码
● 第二步:【A服务客户端】携带【B服务认证服务】的用户名和密码向【B服务认证服务】发起请求获取token。
● 第三步:【B服务认证服务】给【A服务客户端】颁发token。
场景
此种模式虽然简单,但用户将B服务的用户名和密码暴露给A服务,需要两个服务信任度很高才能使用。

客户端模式
流程
说明:这种模式其实已经不太属于OAuth2范畴。A服务完全脱离用户,以自己的身份去向B服务索取token。换言之用户无需具备B服务的使用权也可以。完全是A服务与B服务内部交互,与用户无关了。
● 第一步:A服务向B服务索取token。
● 第二步:B服务返回token给A服务。
场景
A服务本身需要B服务资源,与用户无关。

相关文章
|
1天前
|
jenkins 持续交付 调度
项目《神领物流》
本项目为自研物流系统,基于微服务架构实现智能调度与管控,涵盖用户、快递员、司机多端应用。采用GitFlow管理代码,通过Jenkins实现持续集成,提交后自动构建,保障开发效率与系统稳定,类似顺丰速运模式,面向C端提供高效快递服务。(239字)
|
1天前
|
缓存 数据建模 文件存储
EFC&CTO:缓存引发数据不一致问题排查与深度解析
EFC是NAS自研分布式文件系统客户端,近期升级支持多客户端分布式缓存,兼容NAS、CPFS、OSS。因未适配CTO测试,发版时出现data mismatch。排查发现非单纯缓存读旧数据问题,通过NFS挂载验证确认文件系统数据被破坏,挑战超出预期。
|
1天前
|
设计模式 Java 程序员
推荐书籍
推荐多本Java经典书籍:《Head First Java》适合入门,《Java核心技术》深入巩固基础,《Java编程思想》整合设计模式,适合进阶。并发方面有《Java并发编程之美》等,JVM推荐《深入理解Java虚拟机》与《实战JVM》。体系全面,适合不同阶段学习。
|
1天前
|
负载均衡 算法 Java
微服务篇
SpringBoot核心原理是自动装配,通过@SpringBootApplication注解实现配置类、组件扫描与自动配置。其启动流程包括环境初始化、上下文创建与自动化配置。常用起步依赖如web、redis等;支持properties、YAML等配置文件,后加载的覆盖先加载的。项目通过Feign、Ribbon实现服务通信与负载均衡,使用Nacos做注册与配置中心,Sentinel或Hystrix实现限流熔断,Gateway实现网关限流与CORS跨域控制,结合Spring Cloud五大组件构建微服务架构。
|
1天前
|
消息中间件 存储 缓存
MQ篇
本项目采用RabbitMQ、Kafka和EMQ实现异步通信与数据采集。RabbitMQ用于服务解耦、流量削峰,支持多种消息模式与高可用集群;Kafka处理高吞吐用户行为数据,保障实时推荐与数据同步;EMQ基于MQTT协议实现物联网设备与服务器间可靠通信,支持QoS分级与延迟发布,确保消息不丢不重。三者协同提升系统性能与稳定性。
|
1天前
|
Arthas 监控 Java
jvm相关
本节介绍Arthas常用命令:实时监控系统数据(dashboard)、查看JVM线程、内存、系统属性(sysprop)、环境变量(sysenv)、性能计数器(perfcounter)、日志配置(logger)及静态属性(getstatic)等,支持动态修改与诊断,助力Java应用排查问题。
|
1天前
|
运维 NoSQL 测试技术
Redis:内存陡增100%深度复盘
事故源于大KEY在业务高峰时占满带宽,导致Redis内存使用率骤升至100%。虽有淘汰策略,但缓冲区(输入/输出)激增吞噬内存,主线程阻塞,命令无法处理,最终引发GET/SET超时崩溃。根本原因为大KEY与高流量叠加,触发缓冲区溢出,超出实例承载极限。
|
1天前
|
fastjson Java Kotlin
FastJson:大面积故障规避案例
不到两年开发中,已三次踩坑FastJson,版本差异大,使用需谨慎。项目为Kotlin/Java/Groovy混编:Java生态完善;Kotlin语法简洁、支持协程,但工具链兼容差;Groovy用得少,依赖模型辅助。曾因反序列化异常致预发大量报错,排查发现为FastJson隐患所致,影响广泛,令人后怕。
|
1天前
|
Ubuntu Java Linux
Docker
本文介绍Docker基础操作,涵盖镜像打包、容器管理及Dockerfile编写。通过示例演示如何基于Ubuntu镜像构建Java运行环境,打包Spring Boot应用(linuxDemo.jar),并实现容器化部署与端口映射,最终验证服务运行状态,适合初学者快速掌握Docker核心技能。(239字)
|
1天前
|
数据可视化 数据挖掘 BI
性能优化专题
两幅图像展示了数据可视化图表,包含柱状图与折线图的组合,呈现清晰的趋势分析与对比数据,适用于业务报表、数据分析等场景,助力直观理解关键指标变化。