主要問題
我們應該為每個客戶創建一個新的 OAuth 客戶端 ID 和密鑰，還是只為我們應用程式的所有客戶使用一個？
我的一些同事似乎認為，如果我們使用一個，并且它以某種方式泄漏，它將影響所有客戶。因此，如果我們為每個客戶制作一個，我們可以最大限度地減少損失。但我（有限）的理解是，客戶的主要風險僅在于訪問令牌/重繪 令牌泄漏。
如果 OAuth 客戶端 ID 和秘密泄漏，有人可能會嘗試通過網路釣魚讓某人相信他們正在授予我們的應用程式執行操作的權限，而實際上他們實際上是在授予惡意行為者的訪問權限。但這仍然需要客戶接受網路釣魚嘗試。即便如此，它也只會影響那些喜歡它的客戶，而不會影響其他客戶。
我不太確定的部分是在我們發現泄露的客戶端 ID/秘密后我們的行為的影響。我們可能需要洗掉 OAuth 客戶端并創建一個新客戶端，以防止可能泄露的網路釣魚嘗試。
我相信在單個客戶端 ID 模型上，這會中斷所有客戶的所有 API 呼叫，因為我們內部存盤的訪問令牌將是從前一個客戶端 ID（我們剛剛洗掉的那個）生成的令牌。用戶需要打開我們的應用程式，再次登錄他們的 google 帳戶，然后再次單擊“允許”以從我們創建的新客戶端 ID 中獲取新的訪問令牌，以允許我們再次呼叫 API。如果我們為每個客戶使用不同的客戶 ID，我們可以只為一部分客戶或單個客戶執行此程序。
但我也覺得在多客戶端 ID 模型下，如果一個客戶端 ID 泄漏給一個客戶，我們如何確保它不會泄漏給其他客戶？無論如何，您是否不想為所有客戶獲取新的客戶 ID？
我看到以下選項：
- 泄密者可以訪問我們的谷歌云專案，并可以訪問所有活動的客戶端 ID。他們甚至可以讓自己成為新客戶，因此擁有多個客戶 ID 于事無補。
- 泄密者可以訪問我們的內部資料庫并能夠對其進行解密。因此，他們無論如何都可以獲得存盤在資料庫中的所有客戶端 ID，因此擁有多個客戶端 ID 無濟于事。（他們也可能能夠獲得訪問令牌/重繪 令牌，這是一個更大的問題！）
- 有人錯誤地在某些日志檔案或電子郵件中包含了客戶端 ID 和機密。這可能提供對少于完整客戶端 ID 串列的訪問，但我們又如何知道有多少日志檔案泄露或發送了多少電子郵件？不改變所有這些不是一種不好的做法嗎？
如果我忽略任何東西，請幫助我。
這是更多視覺思考者的圖表（資料庫中的值將被加密/加鹽/等）
更新 由于似乎存在混淆，這里是來自auth0.com的術語
資源所有者：School1、School2 等。
客戶端：我們的“應用程式”服務器
資源服務器：Google - 特別是“Google Workspace”或“Google Workspace Admin SDK APIs”（我相信）
授權服務器：谷歌——特別是“谷歌身份”（我相信）
用戶代理：瀏覽器
Is the Client the Resource Owner?: No. School owns the chromebooks and manages the student/teacher accounts using them through Google Workspace.
Is the Client a web app executing on the server?: Yes. We are following "Authorization Code Flow" to get access tokens from Google for each customer. We store them on our private DB.
Customer's experience - They download and run an installer and enter the license activation code. A website with the UI will be hosted. (let's say www.school1.com/App) It can be in their network, on cloud, wherever, they just need to make sure the hosting server's network can access to our internal server (let's say at 1.2.3.4). When opening www.school1.com/App they need to setup a new admin account and login. Then they click a setup button and get google pop up asking to login to their Google account (This is how we get the access token). Then they can interact with the website in their browser clicking buttons to make actions happen.
API flow - Clicks in browser become API calls to our server (1.2.3.4) with info for us to authenticate/authorize them as a valid App customer making the call. If authorized, our server then uses the access token we have stored internally to call the Google APIs.
Optional Background
My company is looking to make a product for schools using Google Workspace to manage their Chromebooks.
Google already has some APIs that we plan to use. We hope to leverage these with our own business logic. As a dummy example let's imagine we know schools want to reboot their Chromebooks every day at a specific time. The issueCommand REST API can be used to do the reboot. Our app would handle the scheduling of calling the API.
To be able to call these APIs requires permission from the Google Workspace administrator using OAuth 2.0 to authorize us to make the requests (No other authorization protocols are supported). There seems to be two ways to do this.
- Service account apparently for server to server applications
- OAuth Client ID apparently for server-side web apps
The service account requires the administrator to log in to their Admin Console and take a bunch of manual steps to grant our app permission, where the OAuth Client ID seems more user friendly. The admin just signs into the google pop up and is shown all the scopes we request, and can just click "Allow"
（還有其他差異，例如即使管理員更改，服務帳戶也將繼續作業，但我們假設我們承諾使用 OAuth 客戶端 ID）
uj5u.com熱心網友回復：
授權碼流程有兩部分：
- 瀏覽器中使用客戶端ID并獲取授權碼的前端通道請求
- 使用客戶端 ID 和密鑰的反向通道請求，以交換令牌代碼
如果這些泄漏，您可以在不影響最終用戶的情況下替換客戶端機密，因為它在 Web 后端和授權服務器之間是私有的。您可能需要重新部署 Web 應用程式，但這應該是您已經制定好的計劃。
不過，我建議保持客戶端 ID 相同。這無論如何都不是秘密，任何最終用戶都可以在應用程式重定向他們登錄時看到它是什么 - 例如，如果他們使用瀏覽器工具查看 HTTP 請求。
您只有一個應用程式，因此請使用一個客戶端 ID 和密碼。嘗試這樣做是行不通的，因為當用戶開始身份驗證時，您還不知道他們是誰，因為他們還沒有確定自己的身份。
以上是標準的 OAuth，我會堅持下去，因為它會產生簡單的代碼和易于管理的解決方案。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/313715.html