共用方式為


原生應用程式

警告

本內容適用於較舊的 Azure AD v1.0 端點。 將 Microsoft 身分識別平台用於新專案。

原生應用程式是可代表使用者呼叫 Web API 的應用程式。 此案例是根據 OAuth 2.0 授權碼授與類型和公用用戶端,如 OAuth 2.0 規格第 4.1 節所述。 此原生應用程式使用 OAuth 2.0 通訊協定,為使用者取得存取權杖。 接著,此存取權杖隨著要求傳送至 Web API,Web API 再授權使用者並傳回所需的資源。

圖表

原生應用程式到 Web API 圖表

通訊協定流程

如果您使用 AD 驗證程式庫,則會為您處理如下所述的大部分通訊協定細節,例如瀏覽器快顯視窗、權杖快取和重新整理權杖的處理。

  1. 原生應用程式使用瀏覽器快顯視窗,對 Azure AD 中的授權端點提出要求。 此要求包含原生應用程式的應用程式識別碼和重新導向 URI (如 Azure 入口網站所示),以及 Web API 的應用程式識別碼 URI。 如果使用者尚未登入,系統會提示他們再次登入
  2. Azure AD 驗證使用者。 如果是多租用戶應用程式,且需要同意才能使用應用程式,則會要求使用者同意 (如果他們還沒有同意)。 表示同意且成功驗證之後,Azure AD 會發出授權碼回應傳回至用戶端應用程式的重新導向 URI。
  3. 當 Azure AD 發出授權碼回應傳回至重新導向 URI 時,用戶端應用程式會停止瀏覽器互動,並從回應中擷取授權碼。 用戶端應用程式會使用此授權碼,傳送要求至 Azure AD 的權杖端點,此要求包含授權碼、用戶端應用程式的詳細資料 (應用程式識別碼和重新導向 URI),以及所需的資源 (Web API 的應用程式識別碼 URI)。
  4. Azure AD 驗證授權碼及用戶端應用程式和 Web API 的相關資訊。 成功驗證後,Azure AD 會傳回兩個權杖:JWT 存取權杖和 JWT 重新整理權杖。 此外,Azure AD 會傳回使用者的基本資訊,例如其顯示名稱和租用戶識別碼。
  5. 用戶端應用程式使用傳回的 JWT 存取權杖,透過 HTTPS,在對 Web API 的要求的 Authorization 標頭中加上 JWT 字串並指定 "Bearer"。 接著,Web API 驗證 JWT 權杖,如果驗證成功,則傳回所需的資源。
  6. 當存取權杖到期時,用戶端應用程式會收到錯誤,指出使用者必須再次驗證。 如果應用程式具有有效的重新整理權杖,它可用來取得新的存取權杖,不會提示使用者重新登入。 如果重新整理權杖到期,應用程式必須再一次以互動方式驗證使用者。

注意

Azure AD 所簽發的重新整理權杖可用來存取多個資源。 例如,如果您的用戶端應用程式有權限呼叫兩個 Web API,重新整理權杖也可用來取得其他 Web API 的存取權杖。

程式碼範例

請參閱「原生應用程式到 Web API」案例的程式碼範例。 請經常回來查看,我們會頻繁新增新的範例。 原生應用程式到 Web API

應用程式註冊

若要將應用程式註冊到 Azure AD v1.0 端點,請參閱註冊應用程式

  • 單一租用戶 - 原生應用程式和 Web API 必須註冊在 Azure AD 的相同目錄中。 Web API 可以設定為公開一組權限,用以限制原生應用程式對其資源的存取權。 用戶端應用程式即可從 Azure 入口網站的 [其他應用程式的權限] 下拉式功能表中,選取所需的權限。
  • 多租用戶 - 首先,原生應用程式僅註冊在開發人員或發行者的目錄中。 第二,設定原生應用程式來指出它運作所需的權限。 當目的地目錄中的使用者或系統管理員同意應用程式時 (使得應用程式可供組織使用),這份必要權限清單會顯示在對話方塊中。 有些應用程式只需要使用者層級權限,亦即組織中的任何使用者都可以同意應用程式。 其他應用程式需要系統管理員層級權限,亦即組織中的使用者無法同意應用程式。 只有目錄管理員才能對需要此權限層級的應用程式表示同意。 當使用者或系統管理員同意時,只有 Web API 會註冊在他們的目錄中。

權杖到期

當原生應用程式使用其授權碼來取得 JWT 存取權杖時,它也會收到 JWT 重新整理權杖。 當存取權杖到期時,重新整理權杖可用來重新驗證使用者,而不需要他們再次登入。 然後,此重新整理權杖用來驗證使用者,結果會產生新的存取權杖和重新整理權杖。

後續步驟