IdentityServer4主题之授权类型

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混合使用

猜你喜欢

转载自www.cnblogs.com/pangjianxin/p/9279865.html