跳至主要內容

应用管理

码匠君2026/3/16大约 8 分钟使用手册使用与管理界面操作操作说明

概述

Dante Cloud 核心认证授权功能是基于支持 OAuth 2.1 协议的 Spring Authorization Server 组件实现。

在 OAuth2 协议中，客户端 是最关键和最核心的概念之一，Dante Cloud 中的 应用管理 就是对 OAuth2 客户端 的管理。

[一]应用管理

[1]应用列表

在应用管理页面，可以查看系统应用列表，并进行相应的管理操作。

应用列表
应用列表

重要

在 Dante Cloud 的设计中，将微服务中各个服务都视作为一个 OAuth2 客户端，这样可以进一步提升系统的安全性。当然，也可以让整个系统更加灵活，例如：如果某个服务需要支持更多不同的授权场景。

因此，您在新建服务之后，需要在 应用管理 模块中为新服务新建一个 客户端，该操作的主要作用是为新服务分配新的 clientId 和 clientSecret。当然，如果您觉得麻烦，也可以服用其它服务的 clientId 和 clientSecret。

[2]关键参数

管理 应用 会涉及到很多参数，这些参数都是 Spring Authorization Server 所需要的参数。

应用参数一
应用参数一
应用参数二
应用参数二

因为参数比较多，这里仅对常用的、必要的参数进行解释说明。对于非必要的、不影响使用的参数将会掠过。感兴趣的朋友可以深入看看 Spring Authorization Server 的源代码。

1.应用名称

起一个名字，用于区分不同的应用

2.应用类型

用于区分当前的 应用 （或者 OAuth2 客户端）的主要用途。

3.认证模式

即当前的 OAuth2 客户端 支持哪些认证模式。目前 Dante Cloud 支持以下认证模式。

  • 授权码模式（Authorization Code Grant）
  • 客户端凭证模式（Client Credentials Grant）—— Dante Cloud 扩展认证模式，支持 REST 接口通过 Scope 进行鉴权
  • 设备码模式（Device Authorization Grant）
  • 密码模式（Resource Owner Password Credentials Grant）—— Dante Cloud 自定义认证模式
  • 社会化模式（Social Credentials Grant）—— Dante Cloud 自定义认证模式
  • 通行密钥模式（WebAuthn Credentials Grant）—— Dante Cloud 自定义认证模式
  • Authorization Code + PKCE
  • OpenID Connect

详细的使用方法，参见：【登录认证模式】

4.客户端验证模式

OAuth2 的很多认证模式，在进入认证逻辑之前，要先对 客户端 的 合法性 进行验证，以增强安全性。主要是针对客户端 clientId 和 clientSecret 的验证。

验证 clientId 和 clientSecret 的方法（即：Spring Authorization Server 中的 ClientAuthenticationMethod 属性）也有很多种，主要有：

  • client_secret_basic
  • client_secret_post
  • client_secret_jwt
  • private_key_jwt
  • tls_client_auth
  • self_signed_tls_client_auth
  • none

因为，其中部分验证方式要么很少使用，要么当前 Dante Cloud 尚不支持。目前主要使用的验证方法是：client_secret_basic、client_secret_post 和 none 三种：

  • client_secret_basic 的含义，即：以 Basic Header 的方式传递 clientId 和 clientSecret。

使用时，以<clientId>:<clientSecret>的格式对客户端凭据进行 Base64 编码，将编码后的值放入到请求的 Authorization Header 中。

'Authorization ': 'Basic ' + Base64.encode(<clientId>:<clientSecret>)
  • client_secret_post

client_secret_post 与 client_secret_basic 作用类似，不同点是：

  • client_secret_post ：将 clientId 和 clientSecret 值直接放入在 POST 的请求体中
  • client_secret_basic：将 clientId 和 clientSecret 值放入在 POST 请求的 Authorization Header 中。

因为作用相似，所以在配置 Spring Authorization Server Client 信息时，通常 client_secret_post 和 client_secret_basic 都是成对出现。

  • none

只有当前的 OAuth2 客户端为 Public Client 时，Client Authentication Methods 参数才能设置为 none。

这意味着该客户端是面向公共开放的或者是用户自己可以保障绝对信任的

5.回调地址

回调地址，即授权码模式中的 redirect_url。

6.是否需要认证确认

在标准的授权码认证模式中，会涉及两个 Web 页面：一个为登录页面，用于用户输入登录认证信息进行登录；另一个为确认页面，用于用户指定具体授权的 Scope。

标准数场景下，这两个页面都需要。但是，在有些场景下，可能就不需要确认页面。

所以，是否需要认证确认 参数的作用，就是用来控制是否需要在授权码认证流程中，显示确认页面。

7.客户端密钥过期时间

一个安全保障性参数，用于设定 clientSecret 的有效期。一旦超过密钥有效期，该 客户端 将无法继续使用。只有修改了 客户端 密钥过期时间之后，才能继续使用。

8.令牌有效期

令牌有效期，是指 Access Token 的有效期，这也是一个重要的参数。令牌有效期到期之后，该令牌将无法再继续使用。对应到前端界面来说，令牌到期之后，用户就只能重新登录系统。

说明

  1. Access Token 的有效期，一定要设定一为一个合理的时间。如果设定的有效期过短，那么就会出现用户需要频繁 登录系统 或者 重新获取 Token。如果设定的有效期过长，那么用户将会长时间不需要登录系统，会降低账户和数据的安全性。
  2. 除了直接从系统获取 Access Token 外，还可以使用 Refresh Token 来获取 Access Token。

9.刷新令牌有效期

刷新令牌有效期，是指 Refresh Token 的有效期，这也是一个重要的参数。刷新令牌有效期到期之后，客户端 将无法使用刷新令牌来获取 Access Token。之只能重新获取新的 Access Token 和 Refresh Token

说明

因为 Refresh Token 也是获取 Access Token 的一种有效途径。所以，刷新令牌有效期通常会设定为一个较长的时间，这样可以保证持续复用 Refresh Token。至于，刷新令牌有效期具体应该设定为多长，可以根据业务需要而定。但是有一个基本原则，就是 刷新令牌有效期 一定要远大于 令牌有效期

10.授权码有效期

授权码有效期，是指授权码认证模式中，返回的 code 的有效期。这是 OAuth2 协议中，保障安全性的一个重要措施。

11.设备激活码有效期

设备激活码有效期，是指设备码模式中，激活码的有效期。这是 OAuth2 协议中，保障安全性的一个重要措施。

12.是否允许重用刷新令牌

刷新令牌 Refresh Token 一旦到期之后，将无法继续使用，只能重新申请新的 Access Token （新的 Access Token 中会包含新的 Refresh Token）。

但是，有些场景下 Refresh Token 到期后，可能还是需要能够继续使用原有 Refresh Token。那么，就可以通过设置 是否允许重用刷新令牌，实现 Refresh Token 的复用。

[二]范围管理

范围管理，是指对 Scope 的管理。Scope 是 OAuth2 协议中最核心的 权限 元素。OAuth2 协议中，就是利用 Scope 来实现鉴权。

提示

OAuth2 中的 Scope，其实有点类似于 RBAC 权限模型中的 Role，但是本质和用法又有较大的不同。想要深入理解，可以参见： 《OAuth 2 中的 Scope 与 Role 深度解析》

[1]范围列表

在范围管理页面，可以查看系统范围列表，并进行相应的管理操作。

范围列表
范围列表

[2]为范围配置权限

新建完范围之后，可以为该范围指定具体的权限。

为范围配置权限
为范围配置权限

注意

这里的 权限 与系统用户的 权限 是同一套权限。这时为了实现统一管理，同时避免理解混淆的一种设计，而且也是 Dante Cloud 特有的功能之一。

重要

虽说 Scope 是 OAuth2 协议中的重要概念之一，但是 OAuth2 并没有为 Scope 提供具体的实现，在 Spring Authorization Server 中，对于 Scope 的鉴权也仅仅是简单的字符串比较。这种设计当然是为了保证更好的扩展性，因此，Scope 具体对应那种类型的权限必须要由 OAuth2 协议的使用者自己实现。

那么，在一个面向 REST API 的应用系统中，必须要自己来实现 REST API 与 Scope 的对应以及具体的鉴权逻辑。

Dante Cloud 基于 Spring Authorization Server 实现了利用 Scope 对 REST API 的鉴权，这也是 Dante Cloud 的特色之一。但是由于在 OAuth2 协议基础之上引入的 RBAC 权限模型，因此在一些授权模式中，通过 Scope 对 REST API 进行鉴权没有意义。目前 Dante Cloud 支持利用 Scope 对 REST API 的鉴权的认证模式，只有 客户端凭证模式（Client Credentials Grant） 和 设备码模式（Device Authorization Grant） 两种。

因为 OAuth2 本身的设计是面向“非人”的设施进行设计的，而 RBAC 权限模型是面向“人”的，所以两者在某些方面融合会有问题。详情可以参阅：《OAuth 2 中的 Scope 与 Role 深度解析》