加密与授权 Oauth2.0

已于 2023-12-16 22:22:09 修改
阅读量4.8k 收藏 3
点赞数 2
分类专栏： SpringSecurity 文章标签： 安全 oauth
于 2022-01-05 17:03:29 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Stephen_mu/article/details/122308029
版权

加密算法

对称加密

加密和解密使用同样规则（简称"密钥"，这被称为"对称加密算法"
在这里插入图片描述
缺点：密钥的传递和保存变得尤为重要，一旦密钥丢失，则出现数据安全问题。然而加密方和解密方都有可能丢失密钥。

非对称加密

加密和解密可以使用不同的规则，只要这两种规则之间存在某种对应关系即可，这样就避免了直接传递密钥。

  • 乙方生成公钥和私钥，公钥对外公开，私钥则自己保管
  • 甲方从乙方那获得公钥，用公钥加密信息传递到乙方
  • 乙方使用自己的私钥解密甲方发送过来的加密信息
    在这里插入图片描述
    优势：解密的乙方一方保管私钥，降低了私钥丢失的风险。而对称加密则需要加密解密方都防止丢失密钥，一旦任何一方丢失密钥，则不安全。
    1977年，三位数学家Rivest、Shamir 和 Adleman 设计了一种算法，可以实现非对称加密。这种算法用他们三个人的名字命名，叫做RSA算法。从那时直到现在，RSA算法一直是最广为使用的"非对称加密算法"。

RSA算法的原理: 互质关系，欧拉函数，欧拉定理，模反元素

授权机制

在这里插入图片描述

密码授权

上图是豆瓣web应用的登录页面，它允许用户使用第三方应用账户进行登录。如果我们使用传统的密码授权登录，则需要将自己的第三方账户用户名和密码告诉豆瓣网，然后豆瓣应用拿着用户的第三方信息去第三方应用进行验证，如果信息存在且正确，则第三方应用授权给豆瓣网进行登录。

安全问题：

  1. 豆瓣网为何后续的操作授权会保存用户的第三方应用信息（用户名，密码…），第三方应用肯定也不希望公布自己用户信息给其他应用
  2. 一旦豆瓣网之类的应用被破解，则保存的第三方应用数据也可能跟着被泄露
  3. 豆瓣网拿着拥有的用户信息可以获得用户在第三方应用的所有权限
  4. 用户若想要收回豆瓣网对于第三方应用的权限则需要修改密码，这回导致所有的使用第三方应用登录的应用失去授权

OAuth2.0

名词解释：

  1. Third-party application：第三方应用程序，本文中又称"客户端"（client），即上一节例子中的"豆瓣"。
  2. HTTP service：HTTP服务提供商，本文中简称"服务提供商"，即上一节例子中的Wechat。
  3. Resource Owner：资源所有者，本文中又称"用户"（user）。
  4. User Agent：用户代理，本文中就是指浏览器。
  5. Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。
  6. Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。

OAuth在"客户端"与"服务提供商"之间，设置了一个授权层（authorization layer。“客户端"不能直接登录"服务提供商”，只能登录授权层，以此将用户与客户端区分开来。"客户端"登录授权层所用的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。

"客户端"登录授权层以后，"服务提供商"根据令牌的权限范围和有效期，向"客户端"开放用户储存的资料。
在这里插入图片描述

客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）。OAuth 2.0定义了四种授权方式。

  • 授权码模式（authorization code）
  • 简化模式（implicit）
  • 密码模式（resource owner password credentials）
    客户端模式（client credentials）

注意，不管哪一种授权方式，第三方应用申请令牌之前，都必须先到系统备案，说明自己的身份，然后会拿到两个身份识别码：客户端 ID（client ID）和客户端密钥（client secret）。这是为了防止令牌被滥用，没有备案过的第三方应用，是不会拿到令牌的。

授权码（authorization-code）

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

第一步， 豆瓣网站提供一个链接，用户点击后就会跳转到 WeChat 网站，授权用户数据给 豆瓣 网站使用。下面就是 豆瓣 网站跳转 WeChat 网站的一个示意链接。

https://open.weixin.qq.com/connect/qrconnect
?appid=wxd9c1c6bbd5d59980
&redirect_uri=https%3A%2F%2Fwww.douban.com%2Faccounts%2Fconnect%2Fwechat%2Fcallback
&response_type=code
&scope=snsapi_login
&state=yX4Mo6vQG1c%2523douban-web%2523https%253A%2F%2Fwww.douban.com%2F

上面 URL 中，response_type参数表示要求返回授权码（code），app_id参数让 WeChat 知道是谁在请求，redirect_uri参数是 WeChat接受或拒绝请求后的跳转网址，scope参数表示要求的授权范围（这里是login），state参数是关于状态信息
在这里插入图片描述

第二步，用户跳转后，WeChat网站会要求用户登录，然后询问是否同意给予 豆瓣 网站授权。用户表示同意，这时 WeChat 网站就会跳回redirect_uri参数指定的网址。跳转时，会传回一个授权码，就像下面这样。

https://www.douban.com/accounts/connect/wechat/callback
?code=08127W0w3dbMKX2wgL3w3xeZtQ327W0g
&state=yX4Mo6vQG1c#douban-web#https://www.douban.com/

在这里插入图片描述

第三步，豆瓣 网站拿到授权码以后，就可以在后端，向 WeChat 网站请求令牌。

https://www.douban.com//oauth/token?
appid=wxd9c1c6bbd5d59980
&client_secret=CLIENT_SECRET
&grant_type=authorization_code&
&code=08127W0w3dbMKX2wgL3w3xeZtQ327W0g（这是我们刚从wechat拿到的授权码）
&redirect_uri=CALLBACK_URL

上面 URL 中，appid参数和client_secret参数用来让 WeChat 确认 豆瓣网 的身份（client_secret参数是保密的，因此只能在后端发请求），grant_type参数的值是AUTHORIZATION_CODE，表示采用的授权方式是授权码，code参数是上一步拿到的授权码，redirect_uri参数是令牌颁发后的回调网址。
在这里插入图片描述

第四步，WeChat 网站收到请求以后，就会颁发令牌。具体做法是向redirect_uri指定的网址，发送一段 JSON 数据。

{    
  "access_token":"ACCESS_TOKEN",
  "token_type":"bearer",
  "expires_in":2592000,   
  "refresh_token":"REFRESH_TOKEN",
  "scope":"read",
  "uid":100101,
  "info":{...}
}

上面 JSON 数据中，access_token字段就是令牌，豆瓣 网站在后端拿到了。后面便可以根据此Token内部包含的权限，去读取一些WeChat内授权的资源。

在这里插入图片描述

隐藏式（implicit）

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

第一步，插件 网站提供一个链接，要求用户跳转到 WeChat 网站，授权用户数据给 插件 网站使用。

https://open.weixin.qq.com/connect/qrconnect
?appid=wxd9c1c6bbd5d59980
&redirect_uri=plugin_website_url
&response_type=token
&scope=snsapi_login

上面 URL 中，response_type参数为token，表示要求直接返回令牌。

第二步，用户跳转到 WeChat 网站，登录后同意给予 插件 网站授权。这时，WeChat 网站就会跳回redirect_uri参数指定的跳转网址，并且把令牌作为 URL 参数，传给 插件 网站。

https://plugin.com/callback#token=ACCESS_TOKEN

上面 URL 中，token参数就是令牌，插件 网站因此直接在前端拿到令牌。

注意，令牌的位置是 URL 锚点（fragment，#token=ACCESS_TOKEN)，而不是查询字符串(querystring，?token=ACCESS_TOKEN），这是因为 OAuth 2.0 允许跳转网址是 HTTP 协议，因此存在"中间人攻击"的风险，而浏览器跳转时，锚点不会发到服务器，就减少了泄漏令牌的风险。

在这里插入图片描述

密码式（password）

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

第一步，A 网站要求用户提供 WeChat 网站的用户名和密码。拿到以后，A 就直接向 WeChat 请求令牌。

https://open.weixin.qq.com/connect/token
?appid=wxd9c1c6bbd5d59980
&grant_type=password
&username=USERNAME
&password=PASSWORD

上面 URL 中，grant_type参数是授权方式，这里的password表示"密码式"，username和password是 B 的用户名和密码。

第二步，WeChat 网站验证身份通过后，直接给出令牌。注意，这时不需要跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，A 因此拿到令牌。
这种方式需要用户给出自己的用户名/密码，显然风险很大，因此只适用于其他授权方式都无法采用的情况，而且必须是用户高度信任的应用。

客户端凭证（client credentials）

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

第一步，A 应用在命令行向 WeChat 发出请求。

https://open.weixin.qq.com/connect/token 
?grant_type=client_credentials&
&client_id=CLIENT_ID&
&client_secret=CLIENT_SECRET

上面 URL 中，grant_type参数等于client_credentials表示采用凭证式，client_id和client_secret用来让 WeChat 确认 A 的身份。

第二步，WeChat 网站验证通过以后，直接返回令牌。

这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。

令牌的使用

A 网站拿到令牌以后，就可以向 WeChat 网站的 API 请求数据了。

此时，每个发到 API 的请求，都必须带有令牌。具体做法是在请求的头信息，加上一个Authorization字段，令牌就放在这个字段里面。

在这里插入图片描述

更新令牌

令牌的有效期到了，如果让用户重新走一遍上面的流程，再申请一个新的令牌，很可能体验不好，而且也没有必要。OAuth 2.0 允许用户自动更新令牌。

具体方法是，授权 网站颁发令牌的时候，一次性颁发两个令牌，一个用于获取数据，另一个用于获取新的令牌（refresh token 字段）。令牌到期前，用户使用 refresh token 发一个请求，去更新令牌。

https://open.weixin.qq.com/connect/token 
?grant_type=refresh_token
&client_id=CLIENT_ID
&client_secret=CLIENT_SECRET
&refresh_token=REFRESH_TOKEN

上面 URL 中，grant_type参数为refresh_token表示要求更新令牌，client_id参数和client_secret参数用于确认身份，refresh_token参数就是用于更新令牌的令牌。

授权 网站验证通过以后，就会颁发新的令牌。

塞北沐秋
关注
  • 2
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Oauth 2.0授权流程
哒哒哒
12-04 470
最近业务原因接触到第三方授权的规范 第三方授权方式有很多种，比如每个平台都有相似之处但也有些差别 但是大都遵循Oauth 2.0这一套流程，至于是不是标准的Oauth 2.0就另外一说了 下面详细介绍一下Oauth 2.0的授权流程（代码层面） 1.授权前提条件（以平台为例子） 1)：一般现在平台建立应用其目的是获得平台对建立应用的唯一标识app_id 2)：知晓授权的路径及相关规则
OAuth2.0协议中文版
11-29
OAuth 2.0 协议的安全机制主要包括身份验证、授权、加密、签名等。OAuth 2.0 协议的安全机制能够保护资源拥有者的隐私和安全，防止第三方应用的恶意攻击。 OAuth 2.0 协议的优点 OAuth 2.0 协议的优点主要体现在...
OAuth2客户端明文和用户密码为密文
xzj80927的博客
11-17 2798
一、问题描述： 使用Spring-security-0Auth2:2.5.1 版本，进行用户认证时，一直出现问题： { "error":"invalid_client", "error_description":"Badclientcredentials" } 出现问题的条件： 用户的密码使用明文验证时，不会出现此问题。而把密码验证设置为： bcrypt后，再次获取token时，就会报此问题。 postMan的请求和结果如下： 二、代码： 认证服务安全配置类：主要...
spring security-源码流程分析（五）-oauth默认请求地址（/oauth/token）是如何生效的？
luoxiaomei999的博客
04-06 4526
spring security经常在项目中用到，但是平常只是简单的使用肯定是不够的，我们需要了解深层次的东西，才能在使用的过程中不畏惧，本次打算从demo入手，跟踪源码，剖析security内在 一、@FrameworkEndpoint注解的作用 1、在之前的文章中我们看到AuthorizationServerEndpointsConfiguration配置中配置了AuthorizationEndpoint和TokenEndpoint等，他们都是继承自AbstractEndpoint 2、Author.
SpringBoot学习笔记（十五：OAuth2 ）
最新发布
2401_84093490的博客
05-04 1220
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门，即可获取！{“access_token”:“ACCESS_TOKEN”,“token_type”:“bearer”,“expires_in”:2592000,“refresh_token”:“REFRESH_TOKEN”,“scope”:“read”,“uid”:100101,“info”:{…}}上面 JSON 数据中，access_token字段就是令牌，A 网站在后端拿到了。有些 Web 应用是纯前端应用，没有后
spring security oauth其中的/oauth/token做了哪些
u013911102的博客
09-11 6158
项目场景： 问题描述： 提示：这里描述项目中遇到的问题： 例如：数据传输过程中数据不时出现丢失的情况，偶尔会丢失一部分数据 APP 中接收数据代码： 原因分析： 提示：这里填写问题的分析： 例如：Handler 发送消息有两种方式，分别是 Handler.obtainMessage()和 Handler.sendMessage()，其中 obtainMessage 方式当数据量过大时，由于 MessageQuene 大小也有限，所以当 message 处理不及时时，会造成先传的数据被覆盖，进而.
认证，oAuth！！！
山山而川~
01-20 1872
oAuth2.0 简介 什么是OAuth oAuth 协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是 oAuth 的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此 oAuth 是安全的。 什么是Spring Security Spring Security 是一个安全框架，前身是 Acegi Security，能够为 Spring 企业应用系统提供声明式的安全访问控制。Spring Secu
/oauth/token
qq_39256196的博客
01-24 428
本文主要研究Spring Securitytoken获取流程，token的获取方式有5种，其中授权模式最复杂，故本文以授权模式为基准研究token的获取，废话不多说，先上一张核心源码流程图！
oauth2.0源码分析之oauth/token申请令牌
保护我方程序员
09-02 4379
本期介绍的是在oauth2.0中 , 通过调用oauth/token接口 , 框架是如何给我们申请到JWT令牌的 , 内部做了些什么事情 ? 在分析源码之前 , 我们首先需要知道的是我们需要具备哪些调试条件 , 不然会发现许多奇奇怪怪的错误 (比如通过/oauth/token时出现401) 1.一张oauth2.0的内置表(oauth_client_details) 注意:这里的密码需要用Bcript加密 , 因为源码内部是用Bcript解密的 2.两把钥匙: 一本是后缀为jks的私钥 另一本是后缀为k
OWIN OAuth 2.0 Authorization Server
03-22
关于使用Oauth2.0进行相关接口的授权代码，已经调试，需要配置对应key进行加密授权处理
OAUTH2.0中文规范
10-10
OAuth 2.0 是一种授权框架，旨在解决第三方应用程序安全访问受保护资源的问题，而无需...此外，通过使用访问令牌和刷新令牌，OAuth 2.0 提供了一种安全的机制，使得第三方应用可以在不存储用户密码的情况下进行授权。
spring boot oauth2.0 访问 山东X潮软件单点登录平台 源码实现.pdf
01-05
总之，通过 Spring Boot 集成 OAuth2.0，可以实现与山东X潮软件单点登录平台的无缝对接，为用户提供安全便捷的身份验证体验。正确配置和实施 OAuth2.0 流程，可以有效保护用户数据，同时简化应用的登录和授权流程。
Advanced API Security OAuth 2.0 And Beyond-Apress
03-22
3. **JWT（JSON Web Tokens）与OAuth 2.0的结合**：JWT是用于在各方之间安全传输信息的开放标准，通常与OAuth 2.0一起使用，以实现轻量级的身份验证和授权。书会解释JWT的工作原理，以及如何在API中有效地使用它们。...
Google授权登录获取客户端ID（client_id）和客户端密钥（client_secret）及配置
热门推荐
龚清林的博客
05-07 2万+
1、获取客户端ID（client_id）和客户端密钥（client_secret） 需要去这里https://console.developers.google.com/apis/credentials创建 应用凭据 2、创建好应用凭据之后，可以去https://console.developers.google.com/apis/library把对应的API服务启用（获取授权信息，如果只是获取默认授权信息就不需要操作），这里是Web端（对应的是社交>G+和Google People API） 3、
oauth2.0的 /oauth/token是配制就有的吗？它会自动返回token吗？在哪里使用呢
mywaya2333的博客
03-02 830
拿到 OAuth 2.0 的访问令牌（access token）后，客户端可以使用该令牌来访问受保护的资源服务器（Resource Server）。如果 OAuth 2.0 授权服务器支持多个资源服务器或者不同类型的资源，客户端可以使用同一个访问令牌来访问不同的资源，只要这些资源服务器都信任该授权服务器颁发的访问令牌。总之，访问令牌是客户端与资源服务器之间进行安全通信的重要凭证，用于证明客户端的身份并获取访问受保护资源的权限。资源服务器会验证访问令牌的有效性，并根据令牌中的权限信息来授权用户对资源的访问。
oauth2.0 密码方式认证分析
qq_39584267的博客
08-19 3172
oauth2.0 密码方式认证分析
Oauth2.0 security 中对client-secret的加密
qq_40823552的博客
04-21 6924
简单记录了一下今天踩的巨坑，今天利用Oauth做了单点登录，在网上找的案例，但是在研究中发现数据库中存在这么一下这两条数据 实在是不明白其中的client_secret是如何产生的，利用passwordEncoder.encode()去加密配置文件中的client-secret根本不对，在网上找了很久的资料才找到了一个可用的答案 原本的client加载数据库资源是这么写的 @Override public void configure(ClientDetailsServiceConfigurer
自定义spring security oauth2 /oauth/token以及token失效/过期的返回内容格式
qq_37634156的博客
06-12 1万+
在整合Spring Security Oauth2的时候，获取token的接口/oauth/token的返回内容格式为固定的，如下图所示：而token过期或者无效的返回参数格式如下图所示：实际在我们的项目中有时候会要求自定义返回内容格式，下面分别介绍获取token和token失效/过期的自定义返回内容格式。 2、创建获取token接口返回值的转换类 创建一个类来完成对获取token接口的返回参数进行转换成我们自定义的格式，这里使用到了@JsonSerialize注解，该注解主要用于数据转换，不知
Spring Security Oauth2之获取token流程分析
ityw520的博客
11-28 7147
ClientDetailsService则是读取客户端信息的，也就是根据我们发送/oauth/token请求是存放在Authorization中的username和password，注意这个不是用户的，而是客户端的端点信息。OAuth2Authentication: 这个对象就是将当前授权登录的用户信息，当前授权的是那个客户端信息，还有授权模式是什么，还有一些授权中的其他参数，最终这些数据都会被封装在这个对象中。因为获取token的url是/oauth/token，所以他会进入下面的代码。
shiro与oauth2.0
08-23
Shiro和OAuth2.0是两个独立的身份验证和授权框架。Shiro是一个Java开发的安全框架，提供了身份验证、授权、加密、会话管理等功能，可以用于保护应用程序的安全性。OAuth2.0是一个开放的授权框架，用于通过授权令牌来访问受保护的资源，允许用户授权第三方应用程序代表他们访问受保护的资源。 在实际应用中，Shiro可以与OAuth2.0结合使用。Shiro可以处理身份验证和授权逻辑，并通过OAuth2.0协议进行用户的身份认证和授权操作。这样，Shiro可以充当资源服务器，接收和验证来自OAuth2.0授权服务器的访问令牌，并根据令牌的权限进行授权决策。 总结来说，Shiro和OAuth2.0是两个不同的框架，可以结合使用来实现应用程序的身份验证和授权功能。

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值