探索權限和同意

  • 3 分鐘

與 Microsoft 身分識別平台整合的應用程式遵循一種授權模型，可讓使用者和系統管理員控制資料的存取方式。

Microsoft 身分識別平台會實作 OAuth 2.0 授權通訊協定。 OAuth 2.0 是一種可讓第三方應用程式代表使用者存取 Web 主控資源的方法。 任何與 Microsoft 身分識別平台整合的 Web 託管資源都具有資源識別碼，又稱為應用程式識別碼 URI。

以下是 Microsoft Web 託管資源的一些範例：

  • Microsoft Graph：https://graph.microsoft.com
  • Microsoft 365 Mail API：https://outlook.office.com
  • Azure Key Vault：https://vault.azure.net

對於任何已整合 Microsoft 身分識別平台的的第三方資源也是如此。 上述任何資源都可以定義一組權限，以將該資源的功能切割成較小區塊。 當資源的功能切割成較小的權限集時，第三方應用程式可以建立成只要求其功能運作所需的權限。 使用者和系統管理員可以知道應用程式所能存取的資料。

在 OAuth 2.0 中，這些類型的權限集合稱為「範圍」。 我們也常將其稱為「權限」。 在 Microsoft 身分識別平台，權限以字串值表示。 應用程式透過 scope 查詢參數中指定權限，以要求所需的權限。 身分識別平台支援多個定義明確的 OpenID Connect 範圍，以及資源型權限 (在資源的識別碼或應用程式識別碼 URI 後面附加權限值，以表示每個權限)。 例如，權限字串 https://graph.microsoft.com/Calendars.Read 可用來要求在 Microsoft Graph 中讀取使用者行事曆的權限。

應用程式最常用來要求這些權限的方式，是在對 Microsoft 身分識別平台授權端點的要求中指定範圍。 不過，某些高特殊權限只能透過系統管理員同意來授與。 可利用系統管理員同意端點來要求或授與這種權限。

注意

向 Microsoft 身分識別平台的授權、權杖或同意端點提出要求時，如果 scope 參數中省略資源識別碼，則假定資源為 Microsoft Graph。 例如，scope=User.Read 相當於 https://graph.microsoft.com/User.Read。

權限類型

Microsoft 身分識別平台支援兩種類型的權限：「委派權限」和「僅應用程式存取權限」。

  • 委派權限供已有登入使用者的應用程式使用。 針對這些應用程式，使用者或系統管理員須同意應用程式所要求的權限。 當應用程式呼叫目標資源時，系統就會將代表已登入使用者採取行動的權限委派給該應用程式。

  • 僅應用程式存取權限是由無登入使用者情況下執行的應用程式所使用；例如，作為背景服務或精靈來執行的應用程式。 只有系統管理員可以同意僅應用程式存取權限。

Microsoft 身分識別平台上的應用程式須經同意才能存取所需的資源或 API。 應用程式可能需要知道數種同意才能成功。 如果您要定義權限，您還必須了解使用者如何存取您的應用程式或 API。

有三種同意類型：靜態使用者同意、累加和動態使用者同意，以及管理員同意。

在靜態使用者同意案例，您必須在 Azure 入口網站裡指定所有應用程式設定所需要的權限。 如果使用者 (或系統管理員，視情況而定) 尚未同意此應用程式，則 Microsoft 身分識別平台會提示使用者此刻提供同意。 靜態權限也可讓系統管理員在組織中代表所有使用者授予同意。

雖然在 Azure 入口網站中定義應用程式的靜態使用權限，可讓程式碼保持簡潔，但它可能為開發人員帶來一些問題：

  • 應用程式必須在使用者第一次登入時要求可能會需要的所有權限。 這會導致一長串的權限，讓使用者不願意在初始登入時核准應用程式的存取。

  • 應用程式必須事先知道可能會存取的所有資源。 建立能存取任意數量資源的應用程式並不容易。

使用 Microsoft 身分識別平台端點時，您可以忽略 Azure 入口網站中應用程式註冊資訊裡定義的靜態權限，改為累加要求權限。 您可事先要求一組最低權限，隨客戶使用更多應用程式功能時再要求更多權限。

若要這樣做，您隨時可以在要求存取權杖時於 scope 參數中納入新的範圍，以指定您應用程式所需的範圍，而不需要在應用程式註冊資訊中預先定義它們。 如果使用者尚未同意新增至要求的新範圍，則系統只會提示他們同意新的使用權限。 累加或動態同意只適用於委派權限，不適用於僅應用程式存取權限。

重要

動態同意很方便，但因為管理員同意體驗在同意時不知道這些權限，對於需要管理員同意的權限來說會是重大挑戰。 如果您需要管理員權限，或是您的應用程式使用動態同意，您就必須在 Azure 入口網站中註冊所有權限 (不只是需要管理員同意的權限子集)。 這可以讓租用戶管理員代表其所有的使用者表示同意。

當應用程式需要存取某些特許權限時，則需要管理員同意。 管理員同意可確保在系統管理員授權應用程式或使用者存取組織中的高權限資料之前，有某些額外的控制能力。

代表組織行使的管理員同意仍需要為該應用程式註冊的靜態權限。 如果您需要管理員來代表整個組織表示同意，請在應用程式註冊入口網站中為應用程式設定這些權限。 這可減少組織管理員設定應用程式所需的週期。

在 OpenID Connect 或 OAuth 2.0 授權要求中，應用程式可以使用範圍查詢參數來要求所需的權限。 例如，當使用者登入應用程式時，應用程式會傳送類似下列範例的要求。 已加上分行符號以利閱讀。

GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=
https%3A%2F%2Fgraph.microsoft.com%2Fcalendars.read%20
https%3A%2F%2Fgraph.microsoft.com%2Fmail.send
&state=12345

scope 參數是應用程式所要求的委派權限清單，並以空格分隔。 在資源的識別碼 (應用程式識別碼 URI) 後面附加權限值，以表示每個權限。 在要求範例中，應用程式需要權限來讀取使用者的行事曆，以及以使用者身分傳送郵件。

在使用者輸入認證之後，Microsoft 身分識別平台端點會檢查是否有相符的「使用者同意」記錄。 如果使用者過去未曾同意任何要求的權限，且系統管理員也未代表整個組織同意這些權限，則 Microsoft 身分識別平台會要求使用者授與所要求的權限。