1.认识OAuth2.0

简介: OAuth2.0是一种开放授权协议,允许第三方应用在用户授权下访问其资源,而无需获取用户账号密码。相比传统授权更安全,广泛用于第三方登录、服务间资源共享等场景,支持授权码、简化、密码及客户端四种模式,其中授权码模式最安全,适用于Web应用;简化模式适合无后端的前端应用;密码模式用于高度信任的服务间调用;客户端模式则用于系统间内部通信。Spring Security OAuth2可实现单点登录与服务权限控制。

1.什么是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服务资源,与用户无关


目录
相关文章
|
9月前
|
负载均衡 应用服务中间件 Nacos
Nacos配置中心
本文详细介绍Nacos作为配置中心的实现原理与实战步骤,涵盖配置管理、热更新、共享配置优先级及集群搭建,帮助微服务应用实现配置动态化、高可用部署。
511 4
|
10月前
|
人工智能 缓存 供应链
森马如何用阿里云 AI 网关,轻松实现“AI+业务”高效落地
森马快速实现 AI 转型,通过阿里云 AI 网关(即 Higress 企业版)及注册配置中心 Nacos3.0 实现了多模型多 MCP server 统一接入统一管理统一配置,将存量服务一键转换为 MCP server,使 AI 与生产业务相结合,综合提效 30%。
1379 80
|
10月前
|
人工智能 前端开发 数据库
2025年最适合初学者的AI编程工具Top3:零基础也能写出专业级代码_ai代码生成器推荐
李响团队推荐2025年三款适合零基础的AI编程工具:Lynx AI、CodePal、DevMate。无需代码基础,说句话就能生成程序,帮你快速入门、边用边学,轻松迈入编程世界。
2545 154
|
3月前
|
缓存 前端开发 安全
ReAct推理链的工程化实现与最佳实践
本文介绍向量空间JBoltAI平台基于Spring Boot 3.x与Java 21实现的企业级ReAct推理链架构,涵盖分层设计、模板方法、Function Calling驱动、并发安全机制及推理可视化等核心实践,助力LLM能力可靠落地。
|
6月前
|
前端开发 Java Maven
MinIO的预签名直传机制
我们传统使用MinIo做OSS对象存储的应用方式往往都是在后端配置与MinIO的连接和文件上传下载的相关接口,然后我们在前端调用这些接口完成文件的上传下载机制,但是,当并发量过大,频繁访问会对后端的并发往往会对服务器造成极大的压力,大文件传输场景下,服务器被迫承担数据中转的角色,既消耗大量带宽资源,又形成单点性能瓶颈。这时,我们引入了MinIO的一种预签名机制。
MinIO的预签名直传机制
|
9月前
|
设计模式 人工智能 架构师
面对"祖传代码"不敢动?用这条指令让AI做你的首席重构架构师
面对"屎山"代码不敢动?本文介绍了一套专业的AI重构指令,化身拥有15年经验的首席架构师。它能精准识别代码异味,提供基于设计模式的重构方案,并生成验证清单,帮助开发者安全高效地偿还技术债务。
1006 7
|
9月前
|
机器学习/深度学习 数据采集 自然语言处理
BOSS直聘3B超越Qwen3-32B,更多训练数据刷新小模型极限
BOSS直聘Nanbeige实验室开源Nanbeige4-3B模型,仅30亿参数却在数学、推理、代码等多领域超越320亿参数大模型。通过23万亿高质量token训练、千万级指令微调及双重蒸馏强化学习,实现小模型性能跃升,为端侧部署与低成本推理提供新范式。
1100 5
|
9月前
|
缓存 Java Nacos
@RefreshScope热更新原理
本文深入解析Spring Cloud中@RefreshScope注解实现配置热更新的原理。通过分析其组合注解特性,重点探讨@Scope("refresh")如何借助代理模式与缓存机制,在配置变更时触发Bean重建,结合Nacos动态刷新Environment,实现配置实时生效。
415 0
@RefreshScope热更新原理

热门文章

最新文章