驗證方法

不同的組織對於安全性和驗證有不同的需求。Vault 反映了這種需求，提供了多種驗證方法。Spring Vault 支援多種驗證機制。

外部化登入憑證

首次存取受保護系統的過程稱為安全導入。任何客戶端都需要臨時或永久憑證才能存取 Vault。外部化憑證是保持程式碼高維護性的一個良好模式，但會帶來洩露風險增加的隱憂。

向任何一方洩露登入憑證都允許登入 Vault 並存取底層角色允許的密鑰。選擇適當的客戶端驗證並將憑證注入應用程式需要進行風險評估。

Spring 的 PropertySource 抽象非常適合將組態保留在應用程式程式碼之外。您可以使用系統屬性、環境變數或屬性檔案來儲存登入憑證。每種方法都有其自身的特性。請記住，命令列和環境屬性可以使用適當的作業系統存取權限進行內省。

範例 1. 將 vault.token 外部化到屬性檔案
@PropertySource("configuration.properties")
@Configuration
public class Config extends AbstractVaultConfiguration {

    @Override
    public ClientAuthentication clientAuthentication() {
        return new TokenAuthentication(getEnvironment().getProperty("vault.token"));
    }
}
Spring 允許透過多種方式取得 Environment。當使用 VaultPropertySource 時，透過 @Autowired Environment environment 注入將不會提供 Environment，因為環境 Bean 仍在建構中，而自動裝配會在稍後階段進行。您的組態類別應實作 ApplicationContextAware，並從 ApplicationContext 取得 Environment。

請參閱 SecurePropertyUsage.java，以取得在組件和其他屬性來源中參考屬性的範例。

Token 驗證

Token 是 Vault 內部驗證的核心方法。Token 驗證需要提供靜態 Token。

Token 驗證是預設的驗證方法。如果 Token 洩露給非預期的第三方，該方將獲得 Vault 的存取權，並可以存取目標客戶端的密鑰。

通常，Token 驗證用於 Token 在外部建立和續訂的情況（例如 HashiCorp Vault 服務仲介）。根據實際設定，您可能需要或不需要 Token 續訂和撤銷。有關 TTL 和 Token 撤銷的詳細資訊，請參閱 LifecycleAwareSessionManager。

@Configuration
class AppConfig extends AbstractVaultConfiguration {

    // …

    @Override
    public ClientAuthentication clientAuthentication() {
        return new TokenAuthentication("…");
    }

    // …
}

另請參閱

AppId 驗證

AppId 驗證已在 Vault 中棄用。請改用 AppRole 驗證。

Vault 支援 AppId 驗證，它由兩個難以猜測的 Token 組成。AppId 預設為靜態設定的 spring.application.name。第二個 Token 是 UserId，它是應用程式決定的部分，通常與執行階段環境相關。IP 位址、Mac 位址或 Docker 容器名稱都是很好的範例。Spring Vault 支援 IP 位址、Mac 位址和靜態 UserId（例如透過系統屬性提供）。IP 位址和 Mac 位址以十六進位編碼的 SHA256 雜湊表示。

基於 IP 位址的 UserId 使用本機主機的 IP 位址。

@Configuration
class AppConfig extends AbstractVaultConfiguration {

    // …

    @Override
    public ClientAuthentication clientAuthentication() {
        AppIdAuthenticationOptions options = AppIdAuthenticationOptions.builder()
                .appId("myapp")
                .userIdMechanism(new IpAddressUserId())
                .build();

        return new AppIdAuthentication(options, restOperations());
    }

    // …
}

從命令列產生 IP 位址 UserId 的對應命令是

$ echo -n 192.168.99.1 | sha256sum
包含 echo 的換行符號會導致不同的雜湊值，因此請務必包含 -n 標誌。

基於 Mac 位址的 UserId 從本機繫結裝置取得其網路裝置。組態也允許指定 network-interface 提示來選擇正確的裝置。network-interface 的值是選填的，可以是介面名稱或介面索引（從 0 開始）。

@Configuration
class AppConfig extends AbstractVaultConfiguration {

    // …

    @Override
    public ClientAuthentication clientAuthentication() {

        AppIdAuthenticationOptions options = AppIdAuthenticationOptions.builder()
                .appId("myapp")
                .userIdMechanism(new MacAddressUserId())
                .build();

        return new AppIdAuthentication(options, restOperations());
    }

    // …
}

從命令列產生 Mac 位址 UserId 的對應命令是

$ echo -n 0AFEDE1234AC | sha256sum
Mac 位址以大寫字母指定，且不含冒號。包含 echo 的換行符號會導致不同的雜湊值，因此請務必包含 -n 標誌。

自訂 UserId

更進階的方法讓您可以實作自己的 AppIdUserIdMechanism。此類別必須在您的類別路徑中，並且必須實作 org.springframework.vault.authentication.AppIdUserIdMechanism 介面和 createUserId 方法。Spring Vault 將在每次使用 AppId 驗證以取得 Token 時，透過呼叫 createUserId 來取得 UserId。

MyUserIdMechanism.java
public class MyUserIdMechanism implements AppIdUserIdMechanism {

  @Override
  public String createUserId() {

    String userId = …
    return userId;
  }
}

另請參閱：Vault 文件：使用 App ID 驗證後端

AppRole 驗證

AppRole 允許機器驗證，類似於已棄用的（自 Vault 0.6.1 起）AppId 驗證。AppRole 驗證由兩個難以猜測的（密鑰）Token 組成：RoleId 和 SecretId。

Spring Vault 透過僅提供 RoleId 或同時提供 SecretId 以及從 Vault 擷取 RoleId/SecretId（具有回應解包的推送和拉取模式）來支援 AppRole 驗證。

@Configuration
class AppConfig extends AbstractVaultConfiguration {

    // …

    @Override
    public ClientAuthentication clientAuthentication() {

        AppRoleAuthenticationOptions options = AppRoleAuthenticationOptions.builder()
                .roleId(RoleId.provided("…"))
                .secretId(SecretId.wrapped(VaultToken.of("…")))
                .build();

        return new AppRoleAuthentication(options, restOperations());
    }

    // …
}

Spring Vault 也支援完全拉取模式：如果未提供 RoleId 和 SecretId，Spring Vault 將使用角色名稱和初始 Token 來檢索它們。初始 Token 可能與 TTL 和使用限制相關聯。

@Configuration
class AppConfig extends AbstractVaultConfiguration {

    // …

    @Override
    public ClientAuthentication clientAuthentication() {

        VaultToken initialToken = VaultToken.of("…");
        AppRoleAuthenticationOptions options = AppRoleAuthenticationOptions.builder()
                .appRole("…")
                .roleId(RoleId.pull(initialToken))
                .secretId(SecretId.pull(initialToken))
                .build();

        return new AppRoleAuthentication(options, restOperations());
    }

    // …
}

另請參閱：Vault 文件：使用 AppRole 驗證後端

AWS-EC2 驗證

aws-ec2 驗證後端為 AWS EC2 執行個體提供了一種安全的導入機制，允許自動檢索 Vault Token。與大多數 Vault 驗證後端不同，此後端不需要首先部署或佈建安全性敏感的憑證（Token、使用者名稱/密碼、用戶端憑證等）。相反，它將 AWS 視為受信任的第三方，並使用以密碼編譯方式簽署的動態中繼資料資訊，這些資訊唯一地代表每個 EC2 執行個體。

@Configuration
class AppConfig extends AbstractVaultConfiguration {

    // …

    @Override
    public ClientAuthentication clientAuthentication() {
        return new AwsEc2Authentication(restOperations());
    }

    // …
}

AWS-EC2 驗證預設啟用 nonce 以遵循首次使用信任 (Trust On First Use, TOFU) 原則。任何獲得 PKCS#7 身分中繼資料存取權的非預期方都可以針對 Vault 進行驗證。

在首次登入期間，Spring Vault 會產生一個 nonce，該 nonce 儲存在驗證後端，與執行個體 ID 並列。重新驗證需要傳送相同的 nonce。任何其他方都沒有 nonce，並且可以在 Vault 中發出警報以進行進一步調查。

nonce 保存在記憶體中，並在應用程式重新啟動期間遺失。

AWS-EC2 驗證角色是選填的，預設為 AMI。您可以透過在 AwsEc2AuthenticationOptions 中設定驗證角色來設定它。

另請參閱：Vault 文件：使用 AWS-EC2 驗證後端

AWS-IAM 驗證

aws 驗證後端允許使用現有的 AWS IAM 憑證登入 Vault。

AWS IAM 驗證會建立一個簽署的 HTTP 請求，該請求由 Vault 執行，以使用 AWS STS GetCallerIdentity 方法取得簽署者的身分。AWSv4 簽名需要 IAM 憑證。

IAM 憑證可以從執行階段環境取得，也可以從外部提供。具有已指派 IAM 主體的執行階段環境（例如 AWS-EC2、Lambda 和 ECS）不需要用戶端特定的憑證組態，但可以從其中繼資料來源取得這些憑證。

@Configuration
class AppConfig extends AbstractVaultConfiguration {

    // …

    @Override
    public ClientAuthentication clientAuthentication() {

        AwsIamAuthenticationOptions options = AwsIamAuthenticationOptions.builder()
                .credentials(new BasicAWSCredentials(…)).build();

        return new AwsIamAuthentication(options, restOperations());
    }

    // …
}
範例 2. 使用 AWS-EC2 執行個體設定檔作為憑證來源
@Configuration
class AppConfig extends AbstractVaultConfiguration {

    // …

    @Override
    public ClientAuthentication clientAuthentication() {

        AwsIamAuthenticationOptions options = AwsIamAuthenticationOptions.builder()
                .credentialsProvider(InstanceProfileCredentialsProvider.getInstance()).build();

        return new AwsIamAuthentication(options, restOperations());
    }

    // …
}

AwsIamAuthentication 需要 AWS Java SDK 相依性 (com.amazonaws:aws-java-sdk-core)，因為驗證實作使用 AWS SDK 類型來進行憑證和請求簽署。

您可以透過 AwsIamAuthenticationOptions 設定驗證。

另請參閱

Azure (MSI) 驗證

azure 驗證後端為 Azure VM 執行個體提供了一種安全的導入機制，允許自動檢索 Vault Token。與大多數 Vault 驗證後端不同，此後端不需要首先部署或佈建安全性敏感的憑證（Token、使用者名稱/密碼、用戶端憑證等）。相反，它將 Azure 視為受信任的第三方，並使用可以繫結到 VM 執行個體的受管理服務身分和執行個體中繼資料資訊。

@Configuration
class AppConfig extends AbstractVaultConfiguration {

    // …

    @Override
    public ClientAuthentication clientAuthentication() {

        AzureMsiAuthenticationOptions options = AzureMsiAuthenticationOptions.builder()
                    .role(…).build();

        return new AzureMsiAuthentication(options, restOperations());
    }

    // …
}

Azure 驗證需要有關 VM 環境的詳細資訊（訂用帳戶 ID、資源群組名稱、VM 名稱）。這些詳細資訊可以透過 AzureMsiAuthenticationOptionsBuilder 進行設定。如果保持未設定，AzureMsiAuthentication 會查詢 Azure 的執行個體中繼資料服務以取得這些詳細資訊。

另請參閱

GCP-GCE 驗證

gcp 驗證後端允許使用現有的 GCP (Google Cloud Platform) IAM 和 GCE 憑證登入 Vault。

GCP GCE (Google Compute Engine) 驗證會為服務帳戶建立 JSON Web Token (JWT) 形式的簽名。Compute Engine 執行個體的 JWT 是從 GCE 中繼資料服務使用 執行個體識別 取得的。此 API 會建立可用於確認執行個體身分的 JSON Web Token。

與大多數 Vault 驗證後端不同，此後端不需要首先部署或佈建安全性敏感的憑證（Token、使用者名稱/密碼、用戶端憑證等）。相反，它將 GCP 視為受信任的第三方，並使用以密碼編譯方式簽署的動態中繼資料資訊，這些資訊唯一地代表每個 GCP 服務帳戶。

您可以透過 GcpComputeAuthenticationOptions 設定驗證。

@Configuration
class AppConfig extends AbstractVaultConfiguration {

    // …

    @Override
    public ClientAuthentication clientAuthentication() {

        GcpComputeAuthenticationOptions options = GcpComputeAuthenticationOptions.builder()
				.role(…).build();

		GcpComputeAuthentication authentication = new GcpComputeAuthentication(options,
				restOperations());
    }

    // …
}

另請參閱

GCP-IAM 驗證

gcp 驗證後端允許使用現有的 GCP (Google Cloud Platform) IAM 和 GCE 憑證登入 Vault。

GCP IAM 驗證會為服務帳戶建立 JSON Web Token (JWT) 形式的簽名。服務帳戶的 JWT 是透過呼叫 GCP IAM 的 projects.serviceAccounts.signJwt API 取得的。呼叫者針對 GCP IAM 進行驗證，從而證明其身分。此 Vault 後端將 GCP 視為受信任的第三方。

IAM 憑證可以從執行階段環境取得，也可以從外部以 JSON 等形式提供。JSON 是首選形式，因為它攜帶呼叫 projects.serviceAccounts.signJwt 所需的專案 ID 和服務帳戶識別碼。

@Configuration
class AppConfig extends AbstractVaultConfiguration {

    // …

    @Override
    public ClientAuthentication clientAuthentication() {

        GcpIamCredentialsAuthenticationOptions options = GcpIamCredentialsAuthenticationOptions.builder()
				.role(…).credential(GoogleCredentials.getApplicationDefault()).build();

		GcpIamCredentialsAuthentication authentication = new GcpIamCredentialsAuthentication(options,
				restOperations());
    }

    // …
}

GcpIamCredentialsAuthenticationOptions 需要 Google Cloud Java SDK 相依性 (com.google.cloud:google-cloud-iamcredentials)，因為驗證實作使用 Google API 來進行憑證和 JWT 簽署。

您可以透過 GcpIamCredentialsAuthenticationOptions 設定驗證。

Google 憑證需要維護 Token 生命週期的 OAuth 2 Token。所有 API 都是同步的，因此 GcpIamCredentialsAuthentication 不支援反應式使用所需的 AuthenticationSteps。
GcpIamCredentialsAuthentication 使用 IAM Credentials API，並且是使用已棄用的 IAM API 的已棄用 GcpIamAuthentication 的替代方案。

另請參閱

PCF 驗證

pcf 驗證後端允許 PCF 執行個體登入 Vault。它利用了 PCF 的應用程式和容器身分保證。

PCF 驗證使用執行個體金鑰和憑證來建立一個簽名，該簽名由 Vault 驗證。如果簽名符合，並且可能繫結的組織/空間/應用程式 ID 也符合，則 Vault 會發出一個適當範圍的 Token。

執行個體憑證可從 CF_INSTANCE_CERT 和 CF_INSTANCE_KEY 變數中的檔案取得。

@Configuration
class AppConfig extends AbstractVaultConfiguration {

    // …

    @Override
    public ClientAuthentication clientAuthentication() {

        PcfAuthenticationOptions options = PcfAuthenticationOptions.builder()
                .role(…).build();

        PcfAuthentication authentication = new PcfAuthentication(options,
                restOperations());
    }

    // …
}

PcfAuthenticationOptions 需要 BouncyCastle 程式庫來建立 RSA-PSS 簽名。

您可以透過 PcfAuthenticationOptions 設定驗證。

另請參閱

TLS 憑證驗證

cert 驗證後端允許使用 SSL/TLS 用戶端憑證進行驗證，這些憑證可以是由 CA 簽署的，也可以是自簽署的。

若要啟用 cert 驗證，您需要

  1. 使用 SSL，請參閱 [vault.client-ssl]

  2. 設定一個 Java Keystore，其中包含用戶端憑證和私密金鑰

@Configuration
class AppConfig extends AbstractVaultConfiguration {

    // …

    @Override
    public ClientAuthentication clientAuthentication() {

        ClientCertificateAuthenticationOptions options = ClientCertificateAuthenticationOptions.builder()
                .path(…).build();

        return new ClientCertificateAuthentication(options, restOperations());
    }

    // …
}

另請參閱：Vault 文件：使用 Cert 驗證後端

Cubbyhole 驗證

Cubbyhole 驗證使用 Vault 原語來提供安全驗證工作流程。Cubbyhole 驗證使用 Token 作為主要登入方法。臨時 Token 用於從 Vault 的 Cubbyhole 密鑰後端取得第二個登入 VaultToken。登入 Token 通常具有更長的生命週期，並用於與 Vault 互動。登入 Token 可以從包裝的回應或 data 區段中檢索。

建立包裝的 Token

用於 Token 建立的回應包裝需要 Vault 0.6.0 或更高版本。
範例 3. 建立和儲存 Token
$ vault token-create -wrap-ttl="10m"
Key                            Value
---                            -----
wrapping_token:                397ccb93-ff6c-b17b-9389-380b01ca2645
wrapping_token_ttl:            0h10m0s
wrapping_token_creation_time:  2016-09-18 20:29:48.652957077 +0200 CEST
wrapped_accessor:              46b6aebb-187f-932a-26d7-4f3d86a68319
範例 4. 包裝的 Token 回應使用範例
@Configuration
class AppConfig extends AbstractVaultConfiguration {

    // …

    @Override
    public ClientAuthentication clientAuthentication() {

        CubbyholeAuthenticationOptions options = CubbyholeAuthenticationOptions
                .builder()
                .initialToken(VaultToken.of("…"))
                .wrapped()
                .build();

        return new CubbyholeAuthentication(options, restOperations());
    }

    // …
}

使用儲存的 Token

範例 5. 建立和儲存 Token
$ vault token create
Key                    Value
---                    -----
token                  f9e30681-d46a-cdaf-aaa0-2ae0a9ad0819
token_accessor         4eee9bd9-81bb-06d6-af01-723c54a72148
token_duration         0s
token_renewable        false
token_policies         [root]

$ vault token create -use-limit=2 -orphan -no-default-policy -policy=none
Key                    Value
---                    -----
token                  895cb88b-aef4-0e33-ba65-d50007290780
token_accessor         e84b661c-8aa8-2286-b788-f258f30c8325
token_duration         0s
token_renewable        false
token_policies         [none]

$ export VAULT_TOKEN=895cb88b-aef4-0e33-ba65-d50007290780
$ vault write cubbyhole/token token=f9e30681-d46a-cdaf-aaa0-2ae0a9ad0819
範例 6. 儲存的 Token 回應使用範例
@Configuration
class AppConfig extends AbstractVaultConfiguration {

    // …

    @Override
    public ClientAuthentication clientAuthentication() {

        CubbyholeAuthenticationOptions options = CubbyholeAuthenticationOptions
                .builder()
                .initialToken(VaultToken.of("…"))
                .path("cubbyhole/token")
                .build();

        return new CubbyholeAuthentication(options, restOperations());
    }

    // …
}

剩餘 TTL/可續訂性

從 Cubbyhole 檢索的與非零 TTL 相關聯的 Token 在 Token 建立時開始其 TTL。該時間不一定與應用程式啟動時間相同。為了補償初始延遲，Cubbyhole 驗證會對與非零 TTL 相關聯的 Token 執行自我查詢，以檢索剩餘 TTL。Cubbyhole 驗證不會自我查詢沒有 TTL 的包裝 Token，因為零 TTL 表示沒有相關聯的 TTL。

非包裝 Token 僅透過檢索 Token 無法提供有關可續訂性和 TTL 的詳細資訊。自我查詢將查詢可續訂性和剩餘 TTL。

另請參閱

JWT 驗證

設定 JWT 驗證需要 Token 或 JWT 供應商。您可以透過 JwtAuthenticationOptions 設定驗證。

在 Vault 端，您可以透過啟用 JWT 驗證後端並建立角色來設定 JWT 後端。您可以使用 oidc_discovery_url、jwks_url 或 jwt_validation_pubkeys 來設定 JWT 後端。

@Configuration
class AppConfig extends AbstractVaultConfiguration {

    // …

    @Override
    public ClientAuthentication clientAuthentication() {

        JwtAuthenticationOptions options = JwtAuthenticationOptions.builder()
                .role(…).jwt(…).path(…).build();

        return new JwtAuthentication(options, restOperations());
    }

    // …
}

另請參閱

Kubernetes 驗證

自 0.8.3 版起，Vault 支援使用 Kubernetes Token 的 kubernetes 基礎驗證。

使用 Kubernetes 驗證需要 Kubernetes 服務帳戶 Token，通常掛載在 /var/run/secrets/kubernetes.io/serviceaccount/token。該檔案包含 Token，該 Token 會被讀取並傳送到 Vault。Vault 在登入期間使用 Kubernetes API 驗證其有效性。

設定 Kubernetes 驗證至少需要提供角色名稱

@Configuration
class AppConfig extends AbstractVaultConfiguration {

    // …

    @Override
    public ClientAuthentication clientAuthentication() {

        KubernetesAuthenticationOptions options = KubernetesAuthenticationOptions.builder()
                .role(…).jwtSupplier(…).build();

        return new KubernetesAuthentication(options, restOperations());
    }

    // …
}

您可以透過 KubernetesAuthenticationOptions 設定驗證。

另請參閱

使用者名稱/密碼驗證

使用者名稱/密碼通常是一種終端使用者驗證方案。多個 Vault 驗證後端支援使用使用者名稱和密碼

  • 使用者名稱和密碼 (userpass)

  • LDAP (ldap)

  • Okta (okta，另外支援基於時間的一次性 Token)

  • RADIUS (radius)

UserPasswordAuthenticationOptions 可以與上述所有驗證後端一起使用，因為所有機制的登入 API 類似。設定 UserPasswordAuthenticationOptions 時，請確保使用適當的驗證掛載路徑。

範例 7. 設定 UserPasswordAuthentication
@Configuration
class AppConfig extends AbstractVaultConfiguration {

    // …

    @Override
    public ClientAuthentication clientAuthentication() {

        UserPasswordAuthenticationOptions options = UserPasswordAuthenticationOptions.builder()
                .username(…).password(…).build();

        return new UserPasswordAuthentication(options, restOperations());
    }

    // …
}

另請參閱

驗證步驟

ClientAuthentication 物件描述驗證流程並執行實際的驗證步驟。預先組合的驗證易於使用和設定，並且與同步執行緊密結合。

ClientAuthentication 物件不適用於驗證方法的組合和共用步驟的重複使用，例如將登入負載發佈到 Vault 或從 HTTP 來源檢索驗證輸入。

驗證步驟提供了共用驗證活動的可重複使用性。透過 AuthenticationSteps 建立的步驟以功能樣式描述驗證流程，將實際的驗證執行留給特定的執行器。

範例 8. 儲存的 Token 驗證流程。
AuthenticationSteps.just(VaultToken.of(…));                              (1)
1 僅從 VaultToken 建立 AuthenticationSteps。

單步驗證流程可以從單個輸入建立。宣告多個驗證步驟的流程以 Supplier 或 HttpRequest 開頭，它們提供一個驗證狀態物件，該物件可用於對應或發佈到 Vault 以進行登入。

範例 9. AppRole 驗證流程
AuthenticationSteps.fromSupplier(                                       (1)

    () -> getAppRoleLogin(options.getRoleId(), options.getSecretId()))  (2)

    .login("auth/{mount}/login", options.getPath());                    (3)
1 開始宣告接受 Supplier<T> 的 AuthenticationSteps。狀態物件類型取決於 Supplier 回應類型，該類型可以在稍後的步驟中對應。
2 實際的 Supplier 實作。在本例中建立 Map。
3 透過將狀態物件 (Map) 發佈到 Vault 端點來執行 Vault 登入，以建立 Vault Token。請注意，範本變數會受到 URL 跳脫字元處理。

驗證流程需要執行器來執行實際的登入。我們為不同的執行模型提供兩個執行器

  • AuthenticationStepsExecutor 作為同步 ClientAuthentication 的直接替代品。

  • 用於反應式執行的 AuthenticationStepsOperator。

許多 ClientAuthentication 都帶有靜態 factory 方法，用於為其特定於驗證的選項建立 AuthenticationSteps

範例 10. 同步 AuthenticationSteps 執行
CubbyholeAuthenticationOptions options = …
RestOperations restOperations = …

AuthenticationSteps steps = CubbyholeAuthentication.createAuthenticationSteps(options);

AuthenticationStepsExecutor executor = new AuthenticationStepsExecutor(steps, restOperations);

VaultToken token = executor.login();

Token 生命周期

Vault 的 Token 可以與存活時間相關聯。透過驗證方法取得的 Token 旨在在會話處於活動狀態時使用，並且不應在應用程式處於活動狀態時過期。

Spring Vault 提供了 LifecycleAwareSessionManager，這是一個會話管理員，它可以續訂 Token，直到達到其終止 TTL，然後執行另一次登入以取得與會話相關聯的下一個 Token。

根據驗證方法，登入可以建立兩種 Token

  • VaultToken：封裝實際 Token 的通用 Token。

  • LoginToken：與可續訂性/TTL 相關聯的 Token。

諸如 TokenAuthentication 之類的驗證方法僅建立不攜帶任何可續訂性/TTL 詳細資訊的 VaultToken。LifecycleAwareSessionManager 將對 Token 執行自我查詢，以從 Vault 檢索可續訂性和 TTL。如果啟用自我查詢，VaultToken 將定期續訂。請注意，VaultToken 永遠不會被撤銷，只有 LoginToken 會被撤銷。

直接建立 LoginToken 的驗證方法（所有基於登入的驗證方法）已經提供了設定 Token 續訂所需的所有詳細資訊。從登入取得的 Token 會在會話管理員關閉時由 LifecycleAwareSessionManager 撤銷。