zz：https://blog.csdn.net/daihuimaozideren/article/details/77508642
OAuth2.0有五种授权模式。
（1）授权码模式（Authorization Code）
（2）授权码简化模式（Implicit）
（3）Pwd模式（Resource Owner Password Credentials）
（4）Client模式（Client Credentials）
（5）扩展模式（Extension）
注：文中的client，可理解为浏览器或APP。
但不论哪种模式，都是为了从认证服务器获取Access Token，用来访问资源服务器。
而申请Access Token，需要提交相应信息。例如，client_ID(我是谁)，response_type或grant_typt(申请哪种模式)，scope(申请哪些权限，由授权服务器定义)，redirect_uri(申请结果跳转至哪儿)等。当然不同的模式，提交信息内容也不同。
我们先从简单的模式开始。因为简单模式，申请流程短，安全级别较低，个人感觉可用场景不多。
（一）Client模式
先上流程图。
这里写图片描述
该模式下，并不存在对个体用户授权的行为，被授权的主体为client。因此，该模式可用于对某类用户进行集体授权。
申请该模式时，需要在HTTP request entity-body中提交以下信息。
grant_type：
REQUIRED. Value MUST be set to "client_credentials".
scope：
OPTIONAL. The scope of the access request
当然，可以根据授权服务器的实现，提交其它必要信息。
若申请成功，服务器将返回access token和token有效时间。
附规范中的例子。
Request：
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
Response：
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"example_parameter":"example_value"
}
注：expires_in为token有效时长，单位为秒。
（二）Pwd模式
这里写图片描述
该模式下，需要用户将自身的account ID和password交由client，client将使用它们来申请access token，整个过程会将用户信息暴露。因此，除非client十分可靠（例如硬件设备，系统APP），否则，不建议使用该模式。
申请该模式时，需要在HTTP request entity-body中提交以下信息。
grant_type：
REQUIRED. Value MUST be set to "password".
username：
REQUIRED. The resource owner username.
password：
REQUIRED. The resource owner password.
scope：
OPTIONAL. The scope of the access request
申请成功后，授权服务器将返回access token和token有效时间，以及可选的refresh token，用于在access token过期时进行token更新。
附规范中的例子。
Request：
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=johndoe&password=A3ddj3w
Response：
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
（三）授权码模式
这里写图片描述
该模式是五种授权中最啰嗦的。从流程上看，申请分为两个阶段。首先，需要申请Authorization Code，之后，使用Authorization Code来申请Access Token。
我们以优酷为例，讲述流程。
（A）优酷向用户展示，“我”可以支持QQ、微信、支付宝等第三方式登录。用户选择其中一种，例如QQ，则跳转至QQ界面（User-Agent），通常为WEB界面。此时，若用户未登录，则要求用户登录，若已登录，则询问是否授权，以及展示授权后会获得哪些权限。
（B）用户点击授权，触发申请。
（C）假设授权通过，QQ认证服务器将用户导向优酷事先指定的”重定向URI”（redirection URI），同时附上一个Authorization Code。
（D）优酷收到授权码，附上早先的”重定向URI”，向认证服务器申请Access Token。这一步是在优酷的后台的服务器上完成的，对用户不可见。
（E）认证服务器核对了授权码和重定向URI，确认无误后，向优酷发送访问令牌（access token）和更新令牌（refresh token）。
Authorization Code只能使用一次，且有时间限制，规范建议为10分钟。
申请Authorization Code时，需要在URI的query component中附加以下信息
response_type：
REQUIRED. Value MUST be set to "code".
client_id：
REQUIRED. The client identifier
redirect_uri：
OPTIONAL.
scope:
OPTIONAL. The scope of the access request
state：
RECOMMENDED. An opaque value used by the client to
maintain state between the request and callback. The
redirecting the user-agent back to the client. The
parameter SHOULD be used for preventing cross-site
request forgery.
Authorization Code返回时，URI的query component中的附加信息如下
code：
REQUIRED. The authorization code generated by the
authorization server. The authorization code MUST of
expire shortly after it is issued to mitigate the risk
of leaks. A maximum authorization code lifetime of 10
minutes is RECOMMENDED. The client MUST NOT use the
authorization code more than once. If an authorization
code is used more than once, the authorization server
MUST deny the request and SHOULD revoke (when possible)
all tokens previously issued based on that authorization
code. The authorization code is bound to the client
identifier and redirection URI.
state：
REQUIRED if the "state" parameter was present in the
client authorization request. The exact value received
from the client.
使用Authorization Code申请Access Token时，需要在HTTP request entity-body中提交以下信息。
grant_type：
REQUIRED. Value MUST be set to "authorization_code".
code：
REQUIRED. The authorization code received from the
authorization server.
redirect_uri：
REQUIRED, if the "redirect_uri" parameter was included
in the authorization request, and their values MUST be
identical.
client_id：
REQUIRED, if the client is not authenticating with the
authorization server.
申请成功后，授权服务器将返回access token和token有效时间，以及可选的refresh token。
附规范中的例子。
Request Authorization Code：
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com
Authorization Code Response：
HTTP/1.1 302 Found Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz
Request Access Token：
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
Access Token Response：
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
（四）授权码简化模式
这里写图片描述
在授权码模式中，Authorization Code和Access Token都由授权服务器生成和验证，而最终只用到Access Token，这让Authorization Code显得无足轻重。因此，授权码简化模式，去掉了Authorization Code的申请流程，从而通过User-Agent（Browser）直接申请Access Token。
我们还以优酷为例，讲述流程。
（A）优酷向用户展示，“我”可以支持QQ、微信、支付宝等第三方式登录。用户选择其中一种，例如QQ，则跳转至QQ界面（User-Agent），通常为WEB界面。此时，若用户未登录，则要求用户登录，若已登录，则询问是否授权，以及展示授权后会获得哪些权限。
（B）用户点击授权，触发申请。
（C）假设授权通过，QQ认证服务器将用户导向优酷事先指定的”重定向URI”（redirection URI），同时附上Access Token。
（D）QQ界面（User-Agent）收到重定向响应后，向优酷服务器提出请求，表示想提取URI中的Access Token。
（E）优酷服务器返回带有解析脚本的页面，用于解析重定向URI fragment中的Access Token。
（F）User-Agent使用解析脚本，获取Access Token。
（G）User-Agent将Access Token转交给优酷。
申请Access Token时，需要在URI的query component中附加以下信息
response_type：
REQUIRED. Value MUST be set to "token".
client_id：
REQUIRED. The client identifier.
redirect_uri：
OPTIONAL.
scope：
OPTIONAL. The scope of the access request.
state：
RECOMMENDED. An opaque value used by the client to
maintain state between the request and callback. The
authorization server includes this value when
redirecting the user-agent back to the client. The
parameter SHOULD be used for preventing cross-site
request forgery.
Access Token返回时，URI的query component中的附加信息如下
access_token：
REQUIRED. The access token issued by the authorization
server.
token_type：
REQUIRED. The type of the token issued. Value is case
insensitive.
expires_in:
RECOMMENDED. The lifetime in seconds of the access
token. For example, the value "3600" denotes that the
access token will expire in one hour from the time the
response was generated. If omitted, the authorization
server SHOULD provide the expiration time via other
means or document the default value.
scope：
OPTIONAL, if identical to the scope requested by the
client; otherwise, REQUIRED. The scope of the access
token.
state：
REQUIRED if the "state" parameter was present in the
client authorization request. The exact value received
from the client.
注：授权码简化模式，不生成refresh token。
附规范例子。
Access Token Request:
GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com
Access Token Response:
HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
&state=xyz&token_type=example&expires_in=3600
注：此处存在质疑。规范例子中URI不一致，个人认为Response中的URI应为：https://client.example.com/cb。若同学有其他见解，望赐教。
（五）扩展模式
扩展模式，其实是一种自定义模式。规范中仅对“grant type”参数提出了须为URI的要求。对于其他申请数据，可以根据需求进行自定义。
附规范例子。
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-
bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU
[...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
相关推荐
**基于Django 2.1.2的OAuth2.0授权登录详解** OAuth2.0是一种开放标准，用于授权第三方应用访问用户存储在另一服务提供商（如社交媒体网站）上的私有资源，而无需共享用户的登录凭证。在Django框架中实现OAuth2.0...
### OAuth2.0授权框架详解 #### 一、引言 **OAuth2.0**是一种广泛使用的开放标准，用于授权应用程序获取对HTTP服务的受限访问权限。它为资源所有者和HTTP服务之间的交互提供了一种安全的方式，并允许第三方应用以...
《SpringCloud OAuth2.0 实现微服务统一认证授权详解》 在当今的分布式系统架构中，微服务已经成为主流的设计模式。每个微服务都独立部署、独立运行，但随之而来的是如何实现各微服务间的安全通信，这正是OAuth2.0...
### OAuth 2.0 授权协议详解 #### 1. 引言 OAuth 2.0 是一个开放标准，用于授权应用程序访问受保护资源而无需透露用户的凭据。本规范详细介绍了 OAuth 2.0 授权协议的工作原理、角色定义以及实现流程。 #### 1.1 ...
### OAuth2.0规范详解 #### 一、引言 OAuth 2.0是一种开放标准，用于访问控制授权。此规范定义了一套流程，允许一个应用程序（客户端）获取对资源服务器上某用户（资源所有者）数据的受限访问权限。OAuth 2.0取代...
OAuth 2.0 协议定义了多种授权模式，每种模式适用于不同的场景。以下是一些常见的授权模式： 1. **授权码模式**：这是最常用的模式之一，适用于有服务器端的应用程序。在这种模式下，客户端首先重定向用户到授权...
Spring Security OAuth2.0是Spring生态系统中用于实现OAuth2.0授权的组件。它提供了丰富的配置选项，支持多种授权类型，如授权码模式（Authorization Code Grant）、隐式模式（Implicit Grant）、密码模式（Resource...
相较于OAuth 1.0版本，OAuth 2.0更加简洁、灵活，并支持多种授权模式。在移动互联网时代，许多第三方服务，例如支付宝、微信等SDK均采用了OAuth 2.0来进行鉴权处理，以确保用户数据的安全性及应用间的信任关系。 ##...
OAuth 2.0 协议中，还有一个重要的概念是更新令牌，如果用户访问的时候，客户端的"访问令牌"已经过期，则需要使用"更新令牌"申请一个新的访问令牌，客户端发出更新令牌的 HTTP 请求，包含以下参数：grant type：表示...
**laravel passport OAuth2.0的4种模式详解** OAuth2.0是一种授权框架，用于安全地让第三方应用访问用户的数据，而无需分享其原始凭证。laravel passport 是 Laravel 框架提供的一种用于构建 API 的强大工具，它...
OAuth 2.0 支持多种授权模式，包括但不限于： ##### 1. **授权码模式（Authorization Code Grant）** - 用户访问客户端提供的链接，被重定向到授权服务器。 - 用户登录并授权后，被重定向回客户端，并携带授权码...
OAuth 2.0支持四种基本的授权模式： - **授权码模式**（Authorization Code Grant）：最安全的授权模式，适用于有服务器端的应用程序。 - **隐式授权模式**（Implicit Grant）：简化版的授权模式，适用于无服务器端...
在开始使用OAuth2.0授权流程之前，开发者需要完成一些基本的准备工作： - **创建应用**：联系平台管理员创建一个应用，获取`client_id`和`client_secret`。 - **理解授权类型**：了解平台支持的不同授权类型及其...
### OAuth 2.0 中文译本核心知识点详解 #### 一、背景知识与重要性 **OAuth 2.0** 是一个开放标准，用于实现应用程序间的授权过程，特别是允许第三方应用安全地获取用户的数据访问权限，而无需直接提供用户凭据。...
OAuth 2.0支持多种授权模式，但基本流程如下： 1. **客户端向授权服务器发起授权请求**：用户通过客户端应用登录到授权服务器，并授予应用一定的权限。 2. **授权服务器向资源所有者发起身份验证**：授权服务器会...
OAuth2.0定义了四种主要的授权模式，每种模式都有其特定的应用场景： - **授权码模式（Authorization Code）**：适用于Web应用程序，需要后端服务器参与完成整个授权过程。这种模式提供了最高的安全性。 - **简化...
- 这意味着开发者需要使用Spring Security的其他组件（如JWT、OAUTH2.0的Resource Server等）来实现OAuth2.0的功能。 6. **Spring Security OAuth的未来** - Spring Security OAuth项目将进入维护模式，不再更新...