【OAuth2】授权框架的四种授权方式详解

🎉🎉欢迎来到我的CSDN主页！🎉🎉

🏅我是Java方文山，一个在CSDN分享笔记的博主。📚📚

🌟推荐给大家我的专栏《OAuth 2》。🎯🎯

👉点击这里，就可以查看我的主页啦！👇👇

Java方文山的个人主页

🎁如果感觉还不错的话请给我点赞吧！🎁🎁

💖期待你的加入，一起学习，一起进步！💖💖

请添加图片描述

一、OAuth2的简介

1.什么OAuth2

OAuth 2 是一种授权框架，允许第三方应用通过用户授权的形式访问服务中的用户信息，最常见的场景是授权登录；再复杂一点的比如第三方应用通过 Github 给开发者提供的接口访问权限内的用户信息或仓库信息。OAuth2 广泛应用于 web 、桌面应用、移动 APP 的第三方服务提供了授权验证机制，以此实现不同应用间的数据访问权限。 下面分别从不同角色、授权类型、使用场景及流程的纬度详细介绍 OAuth2

2.OAuth Roles

OAuth 定义了四种角色

  • 资源拥有者 (Resource Owner)
  • 客户端 (Client)
  • 资源服务器 (Resource Server)
  • 授权服务器 (Authorization Server)

资源拥有者其实就是真实的用户，用户授权给第三方应用访问在其他系统的用户信息。第三方应用访问授权用户的信息范围 scope 属于申请接入服务时选择的权限之内(例如：读或写访问权限)

资源服务控制用户的信息，授权服务验证用户提供的信息是否正确并返回 access token 给第三方应用。 站在第三方开发者的角度看，被接入的系统提供的服务 API 同时实现了资源和授权角色。在这里把资源服务端和授权服务端统一为“服务角色或 API 角色”。

客户端就是要求接入的第三方应用，获取用户在提供服务的系统的账户信息。对于客户端而言，最终获取到用户在服务端的账户信息首先需要用户授权，用户授权后传给提供服务端验证成功之后返回 access token ，在通过 access token 请求提供服务的系统（在这里我们成为 API ，下文也是）获取用户在 API 中的账户信息。

3.授权流程

接下来文中提到的客户端均为第三方应用，服务端均为被接入的服务。譬如拉勾网有微博登录功能，那么拉勾网就是客户端，微博就是服务端。

刚刚解释了 OAuth 系统中角色的概念，接下来可以解释整个授权的流程。

流程图解释：

  1. 用户点击客户端提供的授权请求
  2. 客户端请求服务的授权页面呈现给用户，用户点击确认授权后服务端返回授权许可凭证给客户端
  3. 客户端通过步骤二接收到的授权许可凭证及在服务端注册的应用信息请求服务端
  4. 如果步骤三验证通过服务端则返回 access token 给客户端
  5. 客户端通过第四步获取的 access token 请求服务端获取资源
  6. 如果服务端校验 access token 成功，则返回指定资源给客户端

以上步骤是 OAuth2 授权登录的步骤，当然不同类型的授权许步骤会不一样，下文会详细逐一讨论。

二、第三方应用创建

第三方接入某平台的 OAuth 2 服务之前，通常需要在平台提供的注册网站（通常叫做 developer" or "API"）新建一个应用，注册成功之后平台会生成应用的 ID 和密码。 读者可以访问 Github 的开发中心看看，国内写的规范的有 coding developer

在平台的注册页面至少得提供如下信息

  • 应用名称
  • 应用网址
  • 回调链接

回调域名的作用：用户点击同意按钮之后，服务端向客户端返回授权码或 access token ,当然如果是禁止操作也需回调告知客户端结果。

在 OAuth 2 服务提供平台新建一个应用之后，平台会提供一对客户端 ID 和密码作为客户端凭证。客户端 ID 是可以公开的字符串，用以构建授权请求链接；用户授权之后，客户端使用服务端的授权码和平台分配的密码获取 access token 。密码应当妥善保管以免泄漏。

 

1.授权许可

在第一张授权流程图中，前四步包含了获取授权许可获取 access token ,授权许可有四种类型，服务端返回哪种类型取决于客户端在请求链接中构建的 response_type 参数。四种类型的授权许可有不同的应用场景：

  • 授权码：通过授权码，服务端通过 Ajax 把 access token 返回给客户端
  • 隐式：用于移动 APP 或 web 应用（应用运行在用户的设备上）
  • 用户密码凭证：同一个公司不同系统之间内部账户互联互通，比如国内某社区的代码托管系统通过社区的账户也可以登录。
  • 客户端凭证：第三方应用自身服务访问提供 OAuth2 服务提供的平台资源

 

1.1.授权码 (Grant Type: Authorization Code)

授权码是 OAuth2 授权最广泛的方式，得益于平台给第三方应用分配的 ID 和密码都是隐藏在第三方应用的后端代码中。因为授权码是基于重定向的方式，要想使用授权码的方式，第三方应用必须能够调用用户系统中的应用（譬如浏览器）、和提供一个接口接收平台服务的回调获取授权码。

一步步解释授权码的流程图

步骤一：构建获取授权码请求链接
下文提到的例子都是基于 digiterocean 的 OAuth2

第一步是构建一个请求 Auth Server 获取授权码的链接，向服务端发起请求

https://cloud.digitalocean.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

分解请求链接：

  • https://cloud.digitalocean.com/v1/oauth/authorize 表示服务端授权 endpoint
  • client_id 平台分配给第三方应用的 ID
  • redirect_uri=CALLBACK_URL 第三方开发者在平台新建第三方应用时填写的回调 URL
  • response_type=code 指定服务端返回授权码
  • scope=read 指定第三方应用请求权限类型
步骤二：用户授权给第三方应用

当用户点击第一步构建的链接之后，在用户已经登录服务端之后才能点击确认授权（譬如想通过微信登录某个第三方网址，你必须首先已经登录微博）。这是平台会给用户提供一个页面给用户确认是否授权。

步骤三：服务端给客户端返回授权码

当用户点击同意授权之后，服务端发起一个请求重定向到第三方平台填写的回调链接，且请求链接中同时包含了服务端生成的授权码。

https://dropletbook.com/callback?code=AUTHORIZATION_CODE
步骤四：第三方应用请求服务端，获取 access token

客户端获取到服务端返回的授权码之后，接着使用授权码和平台分配的密码请求服务端获取服务端的 access token 。第三方应用后端代码拼接的 URL 格式形似：

https://cloud.digitalocean.com/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL

在这里需注意两个参数，其一是 client_secret 没有暴露出去，在第三方应用后端代码中拼接请求链接；另一是 redirect_uri ，这里不是在平台新建应用时填写的回调链接，而是第三方应用已经实现的另一个 action 处理服务端返回 access token 的请求。

步骤五：第三方应用接收 access token

如果第四部客户端发送的信息被服务端校验成功，服务端则返回 access token ，有一些平台同时也同时传递 refresh token 。返回的 json 信息形似：

{
"access_token":"ACCESS_TOKEN",
"token_type":"bearer",
"expires_in":2592000,
"refresh_token":"REFRESH_TOKEN",
"scope":"read",
"uid":100101,
"info":{"name":"Mark E. Mark","email":"mark@thefunkybunch.com"}
}

至此，已经走完 oauth 2 授权码的方式所有流程。在 access_token 没有失效的前提下，可通过 access_token 可以访问平台服务端提供的资源。另外如果还提供了 refresh_token ，在 access_token 失效的情况下，可以通过 refresh_token 再次去获取有效的 access_token 。

 

1.2.隐式 (Grant Type: Implicit)

相比授权码的授权许可这种后端实现，隐式授权类型在应用于前端实现（移动客户端或者浏览器），其缺陷就是并不保证平台分配给第三方平台的密码凭证足够安全。隐式授权同样也是基于重定向的方式，但是 access_token 通过网页重定向返回给第三方平台而不是通过接口调用的方式 暴露了 access_token 在重定向链接中，这点和授权码不同。另外，也不支持服务端校验客户端第三方应用密码，只是依赖在平台新建应用是填写的回调链接。

隐式授权不支持 refresh_token

授权大概流程如下：用户请求授权，同意授权后服务端把 access_token 拼接到回调链接上通过浏览器重定向到客户端，然后客户端获取到 access_token 。

通过流程图可看出在第三步和授权码不同的是服务端重定向到网页而不是通过接口把 access_token 返回给客户端。

步骤一：构建隐式授权请求链接

与授权码的步骤一差不多一致，只是 response_type 字段的参数值为 token

步骤二：用户授权给第三方

与授权码授权的步骤二完全一致

步骤三：通过服务端重定向链接，User-agent (浏览器或者 APP) 获取 access_token

与授权码不同的是，用户点击授权之后服务端通过把 access_token 通过网页重定向到回调链接，客户端通过重定向链接才能获取到 access_token ；而授权码获取 access_token 是通过服务端通过 ajax 请求的形式直接访问第三方应用的后端接口，把 access_token 传给第三方后端。

步骤三：前端根据重定向调整

前端浏览器重定向请求第三方平台的后端

步骤五：第三方应用后端通过脚本获取在重定向链接中的 access_token

第三方应用后端通过脚本获取在重定向链接上的 access_token

步骤六：User-Agent 执行第三方应用后端返回的脚本把 access_token 返回给第三方平台后端。

 

1.3用户密码凭证

用户直接给第三方应用提供在提供服务端账号密码，获取服务端的 access_token 。这种授权方式常用于一个企业不同服务之间的账号互联互通。 用户给第三方应用提供账号密码之后，客户端发送 POST 请求给服务端获取 access_token

https://oauth.example.com/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID

如果服务端校验客户端（第三方应用）传过来的账户密码正确，则把 access_token 返回给客户端，用户授权完成。

 

1.4.客户端凭证

这种授权方式常用于第三方应用想要更改自身在服务提供方注册的应用信息，比如更改应用描述或回调链接地址。

第三方应用通过发送服务端分配的 ID 和密码给后端校验，POST 的 URL 格式形似：

https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

Access Token 和 Refresh Token

第三方应用从服务提供平台获取到有效的 access_token 之后，即可根据平台提供的接口访问服务端的资源。

curl -X POST -H "Authorization: Bearer ACCESS_TOKEN""https://api.digitalocean.com/v2/$OBJECT"

如果服务提供平台支持 refresh_token ，那么第三方应用的 access_token 失效之后，可通过 refresh_token 再次获取有效的 access_token

例如 digitalocean 支持第三方应用通过 POST 请求再此获取有效的 access_token

https://cloud.digitalocean.com/v1/oauth/token?grant_type=refresh_token&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_token=REFRESH_TOKEN

请添加图片描述​

到这里我的分享就结束了，欢迎到评论区探讨交流！！

💖如果觉得有用的话还请点个赞吧 💖

 

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.hqwc.cn/news/297176.html

如若内容造成侵权/违法违规/事实不符，请联系编程知识网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

【ZYNQ】ZYNQ7000 XADC 及其驱动示例

【ZYNQ】ZYNQ7000 XADC 及其驱动示例

XADC 简介 ZYNQ SoC 的 XADC 模块包括两个 12 位的模数转换器，转换速率可以达到 1MSPS（每秒一百万次采样）。它带有片上温度和电压传感器，可以测量芯片工作时的温度和供电电压。 在 7 系列的 FPGA 中，XADC 提供了 JTA…
阅读更多...
蓝桥小课堂-平方和【算法赛】

蓝桥小课堂-平方和【算法赛】

问题描述 蓝桥小课堂开课啦！ 平方和公式是一种用于计算连续整数的平方和的数学公式。它可以帮助我们快速求解从 1 到 n 的整数的平方和，其中 n 是一个正整数。 平方和公式的表达式如下： 这个公式可以简化计算过程，避免逐个计算…
阅读更多...
指标体系构建-03-交易型的数据指标体系

指标体系构建-03-交易型的数据指标体系

参考： 本文参考 1.接地气的陈老师的数据指标系列 2.科普 | 零售行业的数据指标体系及其含义、应用阶段 3.”人货场”模型搞懂没？数据分析大部分场景都能用！ 4.一分钟读懂广告投放各计费CPM、CPC等（公式推导干货） 5.AA…
阅读更多...
用友时空KSOA UploadImage任意文件上传漏洞

用友时空KSOA UploadImage任意文件上传漏洞

漏洞描述 用友时空 KSOA 是根据流通企业前沿的IT需求推出的统的IT基础架构，它可以让流通企业各个时期建立的 IT 系统之间彼此轻松对话。由于用友时空设备开放了文件上传功能，但未鉴权且上传的文件类型、大小、格式、路径等方面进行严格的限制和过滤&…
阅读更多...
电子电器架构（E/E）演化 —— 主流主机厂域集中架构概述

电子电器架构（E/E）演化 —— 主流主机厂域集中架构概述

电子电器架构（E/E）演化 —— 主流主机厂域集中架构概述 我是穿拖鞋的汉子，魔都中坚持长期主义的汽车电子工程师。 老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师： 屏蔽力是信息过载时代一个人的特殊竞争力，任何消耗你的人和事，多看一眼都是你的不对。…
阅读更多...
Linux安装及管理程序

Linux安装及管理程序

一、Linux应用程序管理 1、应用程序与系统命令的关系 1.对比系统命令和应用程序的不同 位置： Linux中一切皆为文件 演示内部命令和外部命令 位置 应用程序位置 用途： 命令主要处理系统的基本操作（复制，配置） 应用程…
阅读更多...
前端未死，顺势而生

前端未死，顺势而生

随着人工智能和低代码的崛起，“前端已死”的声音逐渐兴起。前端已死？尊嘟假嘟？快来发表你的看法吧！ 一、“前端已死”因何而来？ 在开始讨论之前，首先要明确什么是“前端”。 所谓前端，主要涉及…
阅读更多...
CentOS7.6安装Redis6.2.6

CentOS7.6安装Redis6.2.6

Redis安装说明 大多数企业都是基于Linux服务器部署项目，且Redis官方也没有提供Windows版本安装包。因此我们会基于Linux系统来安装Redis.此处选择Linux版本为CentOS 7.6 Redis的官方网站地址：https://redis.io/ 1.单机安装Redis 1.1.安装Redis依赖 …
阅读更多...
Unity与Android交互（双端通信）

Unity与Android交互（双端通信）

前言 最近小编开始做关于手部康复的项目，需要Android集成Unity，以Android为主，Unity为辅的开发；上一篇给大家分享了Unity嵌入Android的操作过程，所以今天想给大家分享一下双端通信的知识； 一. Android与Un…
阅读更多...
mysql原理--连接查询的成本

mysql原理--连接查询的成本

1.准备工作 连接查询至少是要有两个表的，只有一个 single_table 表是不够的，所以为了故事的顺利发展，我们直接构造一个和 single_table 表一模一样的 single_table2 表。为了简便起见，我们把 single_table 表称为 s1 表&#xff0…
阅读更多...
【动态规划】斐波那契数列模型

【动态规划】斐波那契数列模型

欢迎来到Cefler的博客😁 🕌博客主页：那个传说中的man的主页 🏠个人专栏：题目解析 🌎推荐文章：题目大解析（3） 前言 算法原理 1.状态表示 是什么？dp表(一维数组…
阅读更多...
[deepspeed]deepspeed安装和测试代码

[deepspeed]deepspeed安装和测试代码

deepspeed官方对linux系统支持非常好，安装流程较为简单，推荐使用linux系统使用deepspeed.deepspeed由于要使用大模型进行训练和推理，建议显存>24GB。windows上官方不直接支持，但是网上有安装whl文件，只能0.8.3这样老…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023