Class ClientCredentialsFactory

java.lang.Object
io.leandev.appfuse.security.auth.ClientCredentialsFactory
public class ClientCredentialsFactory extends Object

M2M 憑證產生器（ADR-025）

住 capability 的理由是「零產品變異、錯了就是安全漏洞」：熵不足、用了非密碼學安全的 亂數源、忘了 url-safe 編碼——每個下游都可能各自踩一次，而沒有任何產品理由需要不同做法。 判斷句「這個檔預期會被消費端修改嗎？」答案明確是「不會，也不該」。

消費端只決定存哪裡（憑證的持久化歸參考實作，jar 不擁有 entity——ADR-017），以及 唯一性檢查（需要持久化才做得到，見下）。

不含唯一性重試：client_id 是否已被占用只有持久層知道。呼叫端應以 newClientId() 產生後查重、衝突則重試（10 位 base64url ≈ 60 bits，實務上碰撞可忽略， 重試僅為完備）。

產生的是機器憑證——url-safe、高熵、不需人類轉錄；與「給人輸入的密碼」（需考慮可讀性、 字元集限制）是不同的問題，本類不兼任後者。

  • Constructor Details

    • ClientCredentialsFactory

      public ClientCredentialsFactory()
      以預設前綴建立（svc_ / sk_）

    • ClientCredentialsFactory

      public ClientCredentialsFactory(String clientIdPrefix, String clientSecretPrefix)
      Parameters:
      clientIdPrefix - client_id 前綴（可為空字串）
      clientSecretPrefix - client_secret 前綴（可為空字串）；前綴讓憑證在日誌／設定檔中 一眼可辨識種類，便於外洩掃描

  • Method Details

    • newClientId

      public String newClientId()

      產生 client_id（前綴 + base64url 隨機段）

      唯一性由呼叫端對其持久層查重（見類別註解）。

    • newApiKey

      public String newApiKey()

      產生 API key（前綴 ak_ + base64url(32 bytes)）

      與 client_secret 同樣的熵，但用途不同：api-key 是逐請求呈遞的靜態憑證，故驗證端 以 ApiKeyHash（SHA-256）而非慢雜湊比對——高熵是那個選擇成立的前提。

      明文只在此刻存在：呼叫端須立即以 ApiKeyHash.of(String) 雜湊儲存，並且只回傳這一次。

    • newClientSecret

      public String newClientSecret()

      產生 client_secret（前綴 + base64url(32 bytes)）

      明文只在此刻存在——呼叫端須立即雜湊儲存、並且只回傳這一次給建立者。