澄清有關服務到服務中 id_token 使用的問題
在我目前的工作中，我大量使用 OAuth2/OIDC。現在越來越多地轉向 GCP。我有一些關於使用 OIDC 令牌進行服務到服務通信的澄清問題，一個高級，一個戰術：
問題：我將 Cloud Scheduler 作業保護到 Cloud Run 端點。我已經解決了這個問題（據我所知），但我對Google為什麼會這樣設置並希望得到澄清感到非常困惑。不挑戰事物，只尋求理解。感覺和我知道的很不一樣。我一直將 id_tokens 用於人類。
- 為什麼他們選擇 OIDC ID Tokens 進行服務到服務的通信？我在使用者端使用了很多 OIDC，但從未在伺服器到伺服器端使用過。所以為伺服器到伺服器的通信獲取一個 ID Token 感覺很奇怪。我希望有一個指向文件的連結，該文件解釋了伺服器到伺服器端的這種架構選擇。我希望所有服務到服務通信的 OAuth2 訪問令牌都帶有客戶端憑據，而不是 ID 令牌。我看到他們的文件表明該平台同時使用了兩者
- 為什麼 Audience 欄位是任意的？在 Cloud Scheduler 中，似乎只要我在項目中使用有效的服務帳戶，我可以在受眾欄位中輸入任何值嗎？我確信這是有原因的，Google的人很聰明，但這感覺就像一個安全漏洞。我的意思是，觀眾可以是任何有效的網址（我能說得最好）。我可以將 Cloud Run 端點的受眾放在不同的項目中並進行呼叫嗎？
- 顯然 AuthN 和 AuthZ 之間存在分歧，因此 id_token 更多關於 authN，但是根據令牌請求驗證的受眾欄位將指示可靠的 Authz。但由於它是任意的，我覺得觀眾的認可不可信，因為任何人都可以在那裡放任何東西。請告訴我我錯過了什麼。
我希望這些問題是有意義的。我是 GCP 的新手，但就像我所看到的一樣，但我的部分工作是尋找東西的邊緣，與我過去使用的相比，這些感覺很奇怪。
為什麼他們選擇 OIDC ID Tokens 進行服務到服務的通信？我在使用者端使用了很多 OIDC，但從未在伺服器到伺服器端使用過。所以為伺服器到伺服器的通信獲取一個 ID Token 感覺很奇怪。我希望有一個指向文件的連結，該文件解釋了伺服器到伺服器端的這種架構選擇。我希望所有服務到服務通信的 OAuth2 訪問令牌都帶有客戶端憑據，而不是 ID 令牌。
在 Google Cloud 中，有兩種類型的授權。基於角色（OAuth 訪問令牌）和基於身份（OIDC 身份令牌）。基於角色的授權提供對基於角色的所有資源的訪問。例如，查看者可以訪問所有 Compute Engine 實例。這種類型的權限在項目/文件夾/組織級別進行管理。基於身份的授權提供對單個資源的訪問。關鍵區別在於權限/角色的分配位置：在項目級別或在資源級別。由於角色在資源級別的權限過於廣泛，因此您需要另一種方式。那就是身份。我授予john訪問 KMS 密鑰secret2的權限。身份+權限儲存在KMS密鑰訪問管理層。
為什麼 Audience 欄位是任意的？在 Cloud Scheduler 中，似乎只要我在項目中使用有效的服務帳戶，我可以在受眾欄位中輸入任何值嗎？我確信這是有原因的，Google的人很聰明，但這感覺就像一個安全漏洞。我的意思是，觀眾可以是任何有效的網址（我能說得最好）。我可以將 Cloud Run 端點的受眾放在不同的項目中並進行呼叫嗎？
如果您的程式碼創建身份令牌，則需要受眾。某些 Google 管理的 OAuth 客戶端 ID 允許忽略受眾。由於身份和權限儲存在資源中，呼叫不同的 Cloud Run 端點不會通過身份檢查。恕我直言，受眾欄位是身份系統首先檢查身份令牌是否應被批准用於 IAM 層的一種快速方法。
顯然 AuthN 和 AuthZ 之間存在分歧，因此 id_token 更多關於 authN，但是根據令牌請求驗證的受眾欄位將指示可靠的 Authz。但由於它是任意的，我覺得觀眾的認可不可信，因為任何人都可以在那裡放任何東西。請告訴我我錯過了什麼。
身份令牌已簽名。只有授權的服務和程式碼才能創建身份令牌。正如我在前一點中提到的，觀眾不提供權限或授予訪問權限。這是基於身份令牌授權訪問的一層步驟中的一個步驟。最終驗證是在資源上分配的身份+權限。觀眾不會授予任何這些，但可以用作過濾器以快速丟棄令牌。