原生應用程式
警告
本內容適用於較舊的 Azure AD v1.0 端點。 將 Microsoft 身分識別平台用於新專案。
原生應用程式是可代表使用者呼叫 Web API 的應用程式。 此案例是根據 OAuth 2.0 授權碼授與類型和公用用戶端,如 OAuth 2.0 規格第 4.1 節所述。 此原生應用程式使用 OAuth 2.0 通訊協定,為使用者取得存取權杖。 接著,此存取權杖隨著要求傳送至 Web API,Web API 再授權使用者並傳回所需的資源。
圖表
通訊協定流程
如果您使用 AD 驗證程式庫,則會為您處理如下所述的大部分通訊協定細節,例如瀏覽器快顯視窗、權杖快取和重新整理權杖的處理。
- 原生應用程式使用瀏覽器快顯視窗,對 Azure AD 中的授權端點提出要求。 此要求包含原生應用程式的應用程式識別碼和重新導向 URI (如 Azure 入口網站所示),以及 Web API 的應用程式識別碼 URI。 如果使用者尚未登入,系統會提示他們再次登入
- Azure AD 驗證使用者。 如果是多租用戶應用程式,且需要同意才能使用應用程式,則會要求使用者同意 (如果他們還沒有同意)。 表示同意且成功驗證之後,Azure AD 會發出授權碼回應傳回至用戶端應用程式的重新導向 URI。
- 當 Azure AD 發出授權碼回應傳回至重新導向 URI 時,用戶端應用程式會停止瀏覽器互動,並從回應中擷取授權碼。 用戶端應用程式會使用此授權碼,傳送要求至 Azure AD 的權杖端點,此要求包含授權碼、用戶端應用程式的詳細資料 (應用程式識別碼和重新導向 URI),以及所需的資源 (Web API 的應用程式識別碼 URI)。
- Azure AD 驗證授權碼及用戶端應用程式和 Web API 的相關資訊。 成功驗證後,Azure AD 會傳回兩個權杖:JWT 存取權杖和 JWT 重新整理權杖。 此外,Azure AD 會傳回使用者的基本資訊,例如其顯示名稱和租用戶識別碼。
- 用戶端應用程式使用傳回的 JWT 存取權杖,透過 HTTPS,在對 Web API 的要求的 Authorization 標頭中加上 JWT 字串並指定 "Bearer"。 接著,Web API 驗證 JWT 權杖,如果驗證成功,則傳回所需的資源。
- 當存取權杖到期時,用戶端應用程式會收到錯誤,指出使用者必須再次驗證。 如果應用程式具有有效的重新整理權杖,它可用來取得新的存取權杖,不會提示使用者重新登入。 如果重新整理權杖到期,應用程式必須再一次以互動方式驗證使用者。
注意
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 重新整理權杖。 當存取權杖到期時,重新整理權杖可用來重新驗證使用者,而不需要他們再次登入。 然後,此重新整理權杖用來驗證使用者,結果會產生新的存取權杖和重新整理權杖。