警告
此內容適用於較舊的 Azure AD v1.0 端點。 針對新專案使用 Microsoft身分識別平臺。
OAuth2 隱含授與在 OAuth2 規格中具有最長安全性考慮清單的授與是臭名昭著的。 然而，這是 ADAL JS 所實作的方法，也是撰寫 SPA 應用程式時建議的方法。 什麼給予? 這一切都是權衡取捨的問題：事實證明，隱含授與是您可以針對透過瀏覽器透過 JavaScript 取用 Web API 的應用程式所追求的最佳方法。
什麼是 OAuth2 隱含授與？
典型的 OAuth2 授權碼授 與是使用兩個不同端點的授權授與。 授權端點會用於使用者互動階段，這會導致授權碼。 然後，用戶端會使用令牌端點來交換存取令牌的程序代碼，而且通常會使用重新整理令牌。 Web 應用程式必須向令牌端點呈現自己的應用程式認證，讓授權伺服器可以驗證用戶端。
OAuth2 隱式授權是其他授權模式的變體。 它允許用戶端在使用OpenId Connect時，直接從授權端點獲取存取令牌（以及id_token），而無需聯絡令牌端點或驗證用戶端。 此變體是針對在網頁瀏覽器中執行的 JavaScript 型應用程式所設計：在原始的 OAuth2 規格中，令牌會在 URI 片段中傳回。 這讓令牌可供用戶端中的 JavaScript 程式代碼使用，但保證它們不會包含在到伺服器的重定向中。 在 OAuth2 隱含授與中，授權端點會使用先前提供的重新導向 URI，將存取令牌直接發行給用戶端。 它也具有消除跨原始來源呼叫的任何需求的優點，如果需要 JavaScript 應用程式來連絡令牌端點，則這是必要的。
OAuth2 隱含授與的重要特性是這類流程永遠不會將重新整理令牌傳回給用戶端。 下一節說明這並非必要專案，而且實際上是一個安全性問題。
OAuth2 隱含授與的適用案例
OAuth2 規格會宣告已設計隱含授與來啟用使用者代理程式應用程式，也就是說，在瀏覽器中執行的 JavaScript 應用程式。 這類應用程式的定義特性是使用 JavaScript 程式代碼來存取伺服器資源（通常是 Web API），並據以更新應用程式用戶體驗。 想想 Gmail 或 Outlook Web Access 之類的應用程式：當您從收件匣中選取郵件時，只有郵件視覺效果面板會變更以顯示新的選取範圍，而頁面的其餘部分則維持未修改狀態。 此特性與傳統重新導向型 Web 應用程式形成鮮明對比，其中每個使用者互動都會產生完整頁面回傳，以及新伺服器回應的完整頁面轉譯。
極度採用 JavaScript 型方法的應用程式稱為單頁應用程式，或稱為 SPA。 其概念是，這些應用程式只會提供初始 HTML 頁面和相關聯的 JavaScript，而所有後續的互動都是由透過 JavaScript 執行的 Web API 呼叫所驅動。 不過，這些混合式方法並不罕見，其中應用程式主要以回傳驅動為主，但偶爾也會執行 JavaScript 呼叫，隱式流程使用的討論也適用於這種方法。
以重新導向為基礎的應用程式通常會透過 Cookie 保護其要求，不過，這種方法不適用於 JavaScript 應用程式。 Cookie 僅適用於已為其產生的網域，而 JavaScript 呼叫可能會導向其他網域。 事實上，這種情況經常發生：想想調用 Microsoft Graph API、Office API 和 Azure API 的應用程式，這些 API 全都位於應用程式提供服務的網域之外。 JavaScript 應用程式的成長趨勢是完全沒有後端，依賴第三方 Web API 的 100 個% 來實作其商務功能。
目前，保護 Web API 呼叫的慣用方法是使用 OAuth2 持有人令牌方法，其中每個呼叫都會伴隨著 OAuth2 存取令牌。 Web API 會檢查傳入存取令牌，如果它找到所需的範圍，則會授與所要求作業的存取權。 隱含流程為 JavaScript 應用程式提供方便的機制，以取得 Web API 的存取令牌，針對 Cookie 提供許多優點：
- 令牌可以可靠地取得，而不需要跨原始來源呼叫——必須註冊用於令牌回傳的重新導向 URI，保證令牌不會被錯置。
- JavaScript 應用程式可以視需要取得所需數量的存取令牌，針對他們鎖定的 Web API 數目 -- 對網域沒有任何限制
- 會話或本機記憶體等 HTML5 功能授與令牌快取和存留期管理的完整控制權，而 Cookie 管理對應用程式不透明
- 存取令牌不容易受到跨網站要求偽造 （CSRF） 攻擊的影響
隱含授與流程不會發出重新整理令牌，主要是基於安全性考慮。 重新整理令牌並不像存取令牌那樣範圍狹窄，它授予更多權限，因此如果外洩，可能會造成更大的損害。在隱式流程中，令牌會在URL中傳遞，因此攔截的風險高於使用授權碼授權的風險。
不過，JavaScript 應用程式有另一個機制可供更新存取令牌，而不會重複提示使用者輸入認證。 應用程式可以使用隱藏的 iframe 向 Azure AD 的授權端點提出新的令牌請求：只要瀏覽器對 Azure AD 網域仍有有效的會話（即：具備會話 Cookie），驗證請求就能成功進行，無需用戶互動。
此模型會授與 JavaScript 應用程式獨立更新存取令牌的能力，甚至為新的 API 取得新的存取令牌（前提是使用者先前已同意這些令牌）。 這可避免取得、維護和保護高價值物件的額外負擔，例如刷新令牌。 在應用程式外部進行管理的技術元素是 Azure AD 會話 Cookie，它使得靜默更新成為可能。 此方法的另一個優點是，使用者能夠透過任何已登入 Azure AD 的應用程式，從 Azure AD 註銷，並在任何瀏覽器標籤頁中執行。 這會導致刪除 Azure AD 工作階段 Cookie，而 JavaScript 應用程式將自動失去為已登出的使用者更新令牌的能力。
隱含授與是否適合我的應用程式？
隱式授權比其他授權方式存在更多風險，而且需要注意的區域已經有詳細記錄（例如，在隱式流程中誤用存取令牌來模擬資源擁有者和OAuth 2.0 威脅模型和安全考量）。 不過，較高的風險配置檔主要是因為它的目的是讓執行作用中程式代碼的應用程式，由遠端資源提供給瀏覽器。 如果您要規劃 SPA 架構，沒有後端元件，或打算透過 JavaScript 叫用 Web API，建議使用隱含流程來取得令牌。
如果您的應用程式是原生用戶端，則隱含流程並不適合。 原生客戶端內容中缺少 Azure AD 工作階段 Cookie 會剝奪應用程式維護長期會話的方法。 這表示您的應用程式會在取得新資源的存取令牌時重複提示使用者。
如果您要開發包含後端的 Web 應用程式，並從其後端程式代碼取用 API，則隱含流程也不適合。 其他贈款給你更多的權力。 例如，OAuth2 用戶端認證授與可讓您取得令牌，以反映指派給應用程式本身的許可權，而不是使用者委派。 這表示即使使用者未主動參與會話，用戶端仍能夠維護以程式設計方式存取資源的能力， 等等。 不僅如此，這類授與可提供更高的安全性保證。 例如，存取令牌永遠不會透過使用者瀏覽器傳輸，也不會有在瀏覽器歷程記錄中儲存的風險，依序儲存。 用戶端應用程式也可以在要求令牌時執行強身份驗證。
後續步驟
- 如需應用程式整合程式的其他深度，請參閱 如何整合應用程式與 Azure AD 。