Microsoft Graph for Office 365 - Azure AD應用程式許可權

部落格地址：http://blog.csdn.net/FoxDave

前面兩篇文章，我們介紹了基於Azure AD終結點建立應用程式。在本篇文章中，我們來看一下可用的許可權以及如何將它們授予使用者或Azure AD應用程式。

許可權的型別

訪問Microsoft Graph終結點需要發起請求的應用程式或使用者被授予合適的許可權。這些許可權的型別可以是託管許可權或應用程式許可權。

託管的 (以XX的名義)
託管許可權，需要在請求時一同提供使用者上下文。事實上是應用程式以使用者的名義在呼叫Microsoft Graph請求。因此，所需許可權是使用者和應用程式所擁有許可權的集合體。
在請求時使用這兩個有效許可權中結果的交叉部分。如果應用程式被授予了許可權而使用者不具有該許可權，那麼應用程式就無法完成指定的請求。
如果我們對訪問令牌進行解碼，託管許可權會以“scopes”的形式顯示。判斷許可權是否分配並滿足條件的第一步最好是檢查訪問令牌是否有合適的/期望的“scopes”。

應用程式 (app-only或沒有使用者)
應用程式許可權，不需要使用者上下文執行。這種許可權通常的應用為後臺執行的服務或守護應用程式。在請求Microsoft Graph時只判定授予應用程式的許可權。
Azure AD的域管理員往往需要為應用程式許可權的請求進行批准。Azure AD有了一個新的叫做應用程式管理員的角色能夠批准Azure AD應用程式的託管許可權和應用程式許可權，Microsoft Graph和Azure AD Graph除外。
如果我們對訪問令牌進行解碼，應用程式許可權會以“roles"的形式顯示。同樣的，判斷許可權時先檢查”roles“。

許可權命名模式
Microsoft Graph中的所有許可權都依照特定的模式有一個內部名稱：

• Resource.Operation.Constraint

例如：User.Read.All = 當前目錄所有使用者的讀取許可權。

Resource和Operation部分總是指定的，但Constraint是可選的用來定義服務/目錄中的潛在範圍。如果不列出Constraint，則應用到資源的許可權為當前登入使用者。

例如：User.Read = 當前登入使用者的讀取許可權。

下圖是Microsoft Graph中對於給定操作的所需許可權。

注意：所需許可權應秉持最小許可權原則。