第34章授予类型 - Identity Server 4 中文文档(v1.0.0)

授权类型是指定客户端如何与IdentityServer交互的方式。OpenID Connect和OAuth2.0规范定义了以下授权类型：

Implicit
Authorization code
Hybrid
Client credentials
Resource owner password
Device flow
Refresh tokens
Extension grants

你可以在Client的配置中用AllowedGrantTypes 来指定授权类型。

一个客户端可以指定不止一种授权类型（比如Hybrid用于以用户为中心的交互，client_credential用于服务端对服务端的交互），GrantTypes类里面有一些特有的授权类型：

Client.AllowedGrantTypes = GrantTypes.HybridAndClientCredentials;

你也可以指定一个授权类型的列表：

Client.AllowedGrantTypes =

{

    GrantType.Hybrid,

    GrantType.ClientCredentials,

    "my_custom_grant_type"

};

如果想要通过浏览器通道传输access token，你需要显式的允许客户端做如下配置：

Client.AllowAccessTokensViaBrowser = true;

注意

处于安全的因素，不是所有的类型的组合（例如上面的那个列表）被允许的，具体看下面的解释。

本文余下部分将简要描述授权类型，以及何时使用它们。此外，还建议阅读相应的规范，以便更好地理解其中的差异。

34.1 Client credentials

对于服务和服务之间的通讯来说Client credentials是最简单的一种使用场景。这种情况下请求token的是客户端，而不是用户。

这种情况下向令牌端点（token endpoint）发送了一个令牌请求，并获得代表客户端的访问令牌。客户端通常需要使用其client id和secret对令牌端点进行身份验证。

有关如何使用它的示例，请参阅客户端凭据快速入门。

34.2 Resource owner password

这种授权类型允许一个客户端代表用户向令牌端点（token endpoint）发送一个用户名和密码。这是所谓的“非交互”认证，并且通常情况下也是不推荐的。

它存在的一些理由包括一些遗留代码中或者一些集成的场景中，在这种情况下，这种授予类型是有用的，但是一般的建议是使用隐式或混合的交互流来代替用户身份验证。

查看这里可以参考一些关于这方面的参考，通过实现IResourceOwnerPasswordValidator这个接口，你可以提供一些校验username/password的代码。您可以在此处找到有关此接口的更多信息。

34.3 Implicit

隐式的授权类型对基于浏览器的应用进行了优化，用于用户身份验证（包括服务器端和JavaScript应用程序），或身份验证和访问令牌请求（JavaScript应用程序）。

在隐式流中，所有令牌都通过浏览器传输，因此不允许刷新令牌等高级功能。

该快速入门显示了服务器端的web应用程序的认证，而这个显示的JavaScript。

注意

对于基于JavaScript的应用程序，不再推荐使用Implicit。请使用PKCE使用授权码。

34.4 Authorization code

授权码流最初由OAuth2.0指定，并提供了一种在反向通道上检索令牌而不是浏览器前置通道的方法。它还支持客户端身份验证。

虽然这种授权类型本身是受支持的，但通常建议您将其与身份令牌结合使用，将其转换为所谓的混合流。混合流程为您提供重要的额外功能，如签名协议响应。

34.5 Hybrid

混合流是隐式和授权代码流的组合 - 它使用多种授权类型的组合，最典型的是code id_token

在混合流中，身份令牌通过浏览器通道传输，并包含签名的协议响应以及其他工件（如授权代码）的签名。这减轻了许多适用于浏览器通道的攻击。成功验证响应后，反向通道用于检索访问和刷新令牌。

这是希望检索访问令牌（也可能是刷新令牌）的本机应用程序的推荐流程，用于服务器端Web应用程序和本机桌面/移动应用程序。

有关将混合流与MVC一起使用的更多信息，请参阅此快速入门。

34.6 Device flow

设备流程专为无浏览器和输入受限设备而设计，设备无法安全地捕获用户凭据。此流程将用户身份验证和同意外包给外部设备（例如智能手机）。

此流程通常由IoT设备使用，可以请求身份和API资源。

34.7 Refresh tokens

刷新令牌允许获得对API的长期访问。

您通常希望尽可能缩短访问令牌的生命周期，但同时不要一次又一次地通过对IdentityServer进行前端通道往返请求新的令牌来打扰用户。

刷新令牌允许在没有用户交互的情况下请求新的访问令牌。每次客户端刷新令牌时，都需要对IdentityServer进行（经过身份验证的）反向通道调用。这允许检查刷新令牌是否仍然有效，或者在此期间是否已被撤销。

混合，授权代码，设备流和资源所有者密码流支持刷新令牌。要请求刷新令牌，客户端需要在令牌请求中包含offline_access范围（并且必须被授权请求该范围）。

34.8 Extension grants

扩展授权允许使用新的授权类型扩展令牌端点。有关详细信息，请参阅此

34.9 Incompatible grant types

禁止某些授权类型组合：

混合使用隐式和授权码或混合将允许从更安全的基于代码的流降级到隐式。
同样的问题也存在于允许授权码和混合

github地址