共用方式為

授權最佳做法

  • 發行項

當您瞭解如何使用 零信任 原則進行開發時，本文會從取得授權繼續存取資源、開發委派的許可權策略，以及開發應用程式許可權策略。 它可協助您身為開發人員，為您的應用程式實作最佳的授權、許可權和同意模型。

您可以在 需要存取控制的應用程式或解決方案內實作授權 邏輯。 當授權方法依賴已驗證實體的相關信息時，應用程式可以評估在驗證期間交換的資訊（例如，安全性令牌內提供的資訊）。 當安全性令牌不包含資訊時，應用程式可以呼叫外部資源。

您不需要在應用程式中完全內嵌授權邏輯。 您可以使用專用的授權服務來集中進行授權實作和管理。

許可權的最佳做法

Microsoft Entra ID 中採用的最廣泛採用的應用程式遵循同意和授權最佳做法。 檢閱使用 Microsoft Graph 和 Microsoft Graph 許可權參考的最佳做法，以瞭解如何對您的許可權要求深思熟慮。

  • 套用 最低許可權。 只要求必要的許可權。 使用累加式同意來及時要求細微的許可權。 使用 Just-In-Time 和 Just-Enough-Access (JIT/JEA)、風險型調適型原則以及資料保護來限制使用者存取權。

  • 根據案例使用正確的許可權類型。 請避免在同一個應用程式中同時使用應用程式和委派的許可權。 如果您要建置有登入使用者的互動式應用程式，您的應用程式應該使用 委派的許可權。 不過，如果您的應用程式在沒有登入用戶的情況下執行，例如背景服務或精靈，您的應用程式應該使用應用程式許可權。

  • 提供 服務條款和隱私聲明。 使用者同意體驗會向用戶呈現您的服務條款和隱私聲明，以協助他們知道他們可以信任您的應用程式。 對於使用者面向的多租用戶應用程式而言，它們特別重要。

要求許可權的時機

某些許可權需要系統管理員授與租使用者內的同意。 他們可以使用系統管理員同意端點，將許可權授與整個租使用者。 您可以遵循三個模型來要求許可權或範圍。

  • 在登入或第一次存取令牌要求時實作動態使用者同意。 動態使用者同意不需要應用程式註冊中的任何專案。 您可以在特定條件下定義所需的範圍（例如，第一次登入使用者時）。 在您要求該許可權並收到同意之後，您就不需要要求許可權。 不過，如果您沒有在登入或第一次存取時收到動態使用者同意，則會經歷許可權體驗。

  • 視需要要求增量使用者同意。 隨著累加同意與動態使用者同意結合，您不需要一次要求所有許可權。 您可以要求一些許可權，然後在使用者移至應用程式中的不同功能時，您要求更多同意。 這種方法可以增加使用者的舒適等級，因為它們會累加地將許可權授與您的應用程式。 例如，如果您的應用程式要求 OneDrive 存取，如果您也要求行事歷存取，可能會引起懷疑。 相反地，稍後請使用者對其 OneDrive 新增行事曆提醒。

  • /.default使用範圍。 範圍 /.default 有效地模擬了查看您在應用程式註冊中放置內容、找出您需要哪些同意的舊默認體驗，然後要求尚未授與所有同意。 它不需要您在程式代碼中包含所需的許可權，因為它們位於您的應用程式註冊中。

成為已驗證的發行者

Microsoft客戶有時會描述在決定何時允許應用程式透過登入使用者或呼叫 API 來存取 Microsoft 身分識別平台 時發生困難。 在採用 零信任 原則時，他們想要：

  • 提高可見度和控制度。
  • 更主動且更輕鬆的被動決策。
  • 保護數據安全並降低決策負擔的系統。
  • 可信任開發人員的加速應用程序採用。
  • 對發行者已驗證之低風險許可權的應用程式進行限制同意。

雖然存取 Microsoft Graph 等 API 中的數據可讓您建置豐富的應用程式，但您的組織或客戶會評估應用程式要求的許可權，以及應用程式的可信度。

成為 Microsoft已驗證的發行者 ，可協助您讓客戶更輕鬆地接受應用程式要求。 當應用程式來自已驗證的發行者、使用者、IT 專業人員和客戶時，知道它來自Microsoft有業務關係的人。 在發行者名稱旁會出現藍色複選標記（下列許可權要求同意提示範例中的元件 #5;請參閱Microsoft Entra 應用程式同意體驗中的元件數據表）。 使用者可以從同意提示中選取已驗證的發行者，以檢視詳細資訊。

[要求的許可權] 對話框螢幕快照會顯示元件建置組塊，如連結Microsoft Entra 應用程式同意體驗一文所述。

當您是已驗證的發行者時，使用者和IT專業人員會因為身為已驗證的實體而獲得應用程式的信任。 發行者驗證可為您的應用程式提供改良的商標，以及提高透明度、降低風險，以及為客戶更順暢的企業採用。

下一步