原生應用程式

原生應用程式是代表用戶呼叫 Web API 的應用程式。 此案例是以具有公用用戶端的 OAuth 2.0 授權碼授與類型為基礎，如 OAuth 2.0 規格的第 4.1 節所述。 原生應用程式會使用 OAuth 2.0 通訊協定來取得使用者的存取令牌。 接著，此存取令牌會在要求中傳送至 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. 透過 HTTPS，用戶端應用程式會使用傳回的 JWT 存取令牌，將具有「持有人」指定之 JWT 字串新增至 Web API 的要求授權標頭。 接著，Web API 會驗證 JWT 令牌，如果驗證成功，則會傳回所需的資源。
6. 存取令牌到期時，用戶端應用程式會收到錯誤，指出使用者需要再次驗證。 如果應用程式具有有效的重新整理令牌，它可以用來取得新的存取令牌，而不提示使用者再次登入。 如果重新整理令牌過期，應用程式必須再次以互動方式驗證使用者。

程式代碼範例

請參閱原生應用程式到 Web API 案例的程式代碼範例。 而且，我們經常回來查看 -- 我們經常新增範例。 原生應用程式到 Web API。

應用程式註冊

若要向 Azure AD v1.0 端點註冊應用程式，請參閱 註冊應用程式。

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

憑證到期

當原生應用程式使用其授權碼來取得 JWT 存取令牌時，它也會收到 JWT 重新整理令牌。 當存取令牌過期時，重新整理令牌可以用來重新驗證使用者，而不需要他們再次登入。 接著，此重新整理令牌會用來驗證使用者，從而產生新的存取令牌和重新整理令牌。

後續步驟

• 深入瞭解其他 應用程式類型和案例
• 瞭解 Azure AD 驗證基本概念