IdentityServer4主题之授权类型

Posted 2020-12-02 pangjianxin

Grant Types 授权类型

授权类型指出了一个客户端如何与IdentityServer进行交互。OpenID Conect和OAuth2.0定义了如下的授权类型：

• Implicit
• Authorization code
• Hybrid
• Client credentials
• Resource owner password
• 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;

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

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

Client credentials

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

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

点击 Client Credentials Quick Start 查看demo。

Resource owner password

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

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

查看这里可以参考一些关于这方面的参考，通过实现IResourceOwnerPasswordValidator 这个接口，你可以提供一些校验username/password的代码。

Implicit

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

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

This demo演示了诸如MVC这种应用的认证过程， this demo演示了一些JavaScript应用的认证过程。

Authorization code

授权代码流最初是由OAuth 2指定的，它提供了一种方法，可以在反向通道上检索令牌，而不是使用浏览器的前端通道(front-channel)。它还支持客户端身份验证。

虽然这种授权类型本身是受支持的，但通常建议将其与身份令牌组合在一起，从而将其转换为所谓的混合流。混合流为你提供了重要的额外特性，如签名协议响应（signed protocol responses）。

Hybrid

Hybrid是implicit和authorization code的混合。它使用多种授权类型的组合，最典型的是 code id_token.

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

如果本地应用想要检索access token（可能还会有refresh token刷新令牌）的话，那么这种流程就特别合适。另外，他还用户像MVC应用和桌面应用。

查看 this 来获取MVC应用使用这种流程的相关信息。

Refresh tokens

刷新令牌允许对api的长期访问。

您通常希望尽可能短地保留访问令牌的生命周期，但同时又不想一次又一次地打扰用户（进行认证），因为他们会进行前端通道往返来请求一个新的token。

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

刷新令牌适用于hybrid、authentication code和resourceownerpassword这些流程中。为了请求一个刷新令牌，客户端需要在请求中包含一个offline_access的scope（并且这个scope必须通过认证）

Extension grants

授权扩展允许使用新的授权类型来扩展token endpoint，查看这里 this 取得更多的信息。

Incompatible grant types 不能组合在一起的授权类型

一些授权类型的组合是错误的或者禁止的。

• 将implicit和authorization code或者hybrid组合在一起会造成从更安全的基于authorization code流程模式降级到implicit流模式。
• 同样的问题也存在于authorization code和hybrid混合使用