共用方式為


教學課程:在 Azure App Service 中端對端驗證和授權使用者

Azure App Service 提供可高度擴充、自我修復的 Web 裝載服務。 App Service 內建支援使用者驗證和授權。 本教學課程說明如何使用 App Service 驗證和授權來保護您的應用程式。 其會搭配檢視前端使用 Express.js。 App Service 驗證與授權功能支援所有程式語言執行環境。 您可以遵循本教學課程,瞭解如何將它套用至您慣用的語言。

Azure App Service 使用 Linux作系統提供可高度擴充、自我修補的 Web 主機服務。 App Service 內建支援使用者驗證和授權。 本教學課程說明如何使用 App Service 驗證和授權來保護您的應用程式。 其會搭配檢視前端使用 Express.js。 App Service 驗證與授權功能支援所有程式語言執行環境。 您可以遵循本教學課程,瞭解如何將它套用至您慣用的語言。

此程序中的驗證是由 Azure App Service 在裝載平台層提供。 您必須部署前端和後端應用程式,並設定成功使用此 Web 應用程式的驗證。

概念圖顯示從 Web 使用者到前端應用程式到後端應用程式的驗證流程。

完成此案例之後,請繼續進行下一個教學課程,以瞭解如何以已驗證的使用者身分連線到 Azure 服務。 常見的案例包括以具有特定能力或特定資料表或檔案存取權的使用者身分存取 Azure 儲存體或資料庫。

在本教學課程中,您會:

  • 啟用內建驗證和授權
  • 防止應用程式接受未經驗證的要求
  • 使用 Microsoft Entra ID 作為識別提供者
  • 代表已登入的使用者存取遠端應用程式
  • 使用權杖驗證保護服務對服務呼叫
  • 從伺服器程式碼使用存取權杖

必要條件

如果您沒有 Azure 帳戶,請在開始之前建立 免費帳戶

取得使用者設定檔

前端應用程式已設定為安全地使用後端 API。 前端應用程式會為使用者提供 Microsoft 登入,然後允許使用者從後端取得其偽造設定檔。 本教學課程會使用偽造的設定檔,以簡化完成案例的步驟。

在您的原始程式碼在前端執行之前,App Service 會插入來自 App Service accessToken 標頭的已驗證 x-ms-token-aad-access-token。 前端原始程式碼接著會存取並傳送 accessToken 至後端伺服器。 前端伺服器會將令牌傳送為 bearerToken ,以安全地存取後端 API。 後端伺服器會先驗證bearerToken,然後將其傳遞給您的後端原始程式碼。 後端原始程式碼收到 bearerToken之後,就可以使用它。

在本系列 中的下一個教學課程 中,bearerToken 會被交換為具有存取 Microsoft Graph API 範圍的令牌。 Microsoft Graph API 會傳回使用者的設定檔資訊。

複製範例應用程式

Azure Cloud Shell 中,執行下列命令來複製範例存放庫。

git clone https://github.com/Azure-Samples/js-e2e-web-app-easy-auth-app-to-app

建立和部署應用程式

建立資源群組、Web 應用程式方案和 Web 應用程式,然後在單一步驟中部署。

  1. 變更為 frontend Web 應用程式目錄。

    cd js-e2e-web-app-easy-auth-app-to-app/frontend
    
  2. 使用 az webapp up 命令建立及部署前端 Web 應用程式。 Web 應用程式名稱必須是全域唯一的。 以唯一名稱取代 <front-end-app-name>

    az webapp up --resource-group myAuthResourceGroup --name <front-end-app-name> --plan myPlan --sku FREE --os-type Windows --location "West Europe" --runtime "NODE:24LTS"
    
  3. 變更為 backend Web 應用程式目錄。

    cd ../backend
    
  4. 將後端 Web 應用程式部署至相同的資源群組和應用程式方案。 Web 應用程式名稱必須是全域唯一的。 將 <back-end-app-name> 替換為一個獨特的字母和數字組合。

    az webapp up --resource-group myAuthResourceGroup --name <back-end-app-name> --plan myPlan --os-type Windows --location "West Europe" --runtime "NODE:24LTS"
    
  1. 變更為 frontend Web 應用程式目錄。

    cd frontend
    
  2. 使用 az webapp up 命令建立及部署前端 Web 應用程式。 Web 應用程式名稱必須是全域唯一的。 將 <front-end-app-name> 替換為一個獨特的字母和數字組合。

    az webapp up --resource-group myAuthResourceGroup --name <front-end-app-name> --plan myPlan --sku FREE --location "West Europe" --os-type Linux --runtime "NODE:24-lts"
    
  3. 變更為 backend Web 應用程式目錄。

    cd ../backend
    
  4. 將後端 Web 應用程式部署至相同的資源群組和應用程式方案。 Web 應用程式名稱必須是全域唯一的。 將 <back-end-app-name> 替換為一個獨特的字母和數字組合。

    az webapp up --resource-group myAuthResourceGroup --name <back-end-app-name> --plan myPlan --sku FREE --location "West Europe" --runtime "NODE:24-lts"
    

設定應用程式設定

前端應用程式必須知道 API 要求的後端應用程式 URL。 使用下列 Azure CLI 命令來設定應用程式設定。 URL 應該是 https://<back-end-app-name>.azurewebsites.net

az webapp config appsettings set --resource-group myAuthResourceGroup --name <front-end-app-name> --settings BACKEND_URL="https://<back-end-app-name>.azurewebsites.net"

前端會呼叫後端

瀏覽至前端應用程式,並從後端傳回偽造設定檔。 此動作會驗證前端是否成功向後端要求配置檔,而後端會傳回配置檔。

  1. 在瀏覽器中開啟前端 Web 應用程式: https://<front-end-app-name>.azurewebsites.net

    Web 瀏覽器的螢幕快照,其中顯示成功完成驗證之後的前端應用程式。

  2. 選取 [ 取得使用者配置檔 ] 連結。

  3. 檢視從後端 Web 應用程式傳回的 配置檔。

    瀏覽器的螢幕截圖,顯示從伺服器返回的虛假個人資料。

    withAuthenticationfalse 表示尚未設定驗證。

設定驗證

在本節中,啟用兩個 Web 應用程式的驗證和授權。 此教學課程會使用 Microsoft Entra ID 作為識別提供者。

您也會將前端應用程式設定為:

  • 將前端應用程式的存取權授與後端應用程式
  • 設定 App Service,以傳回可使用的權杖
  • 在您的程式代碼中使用令牌

如需詳細資訊,請參閱為 App Service 應用程式設定 Microsoft Entra 驗證

啟用後端應用程式的驗證和授權

  1. Azure 入口網站中,搜尋並選取 [資源群組]

  2. 在 [資源群組] 中,尋找並選取資源群組。 在 [ 概觀] 中,選取您的後端應用程式。

  3. 在後端應用程式的左側功能表中,選取 [ 設定>驗證],然後選取 [新增識別提供者]。

  4. 在 [ 新增識別提供者 ] 頁面中,針對 [ 識別提供者],選取 [Microsoft 以使用 Microsoft 和 Microsoft Entra 身分識別登入。

  5. 選取 [客戶端密碼到期] 的值。

    後端應用程式的左側功能表螢幕快照,其中顯示已選取 [驗證/授權],並在右側功能表中選取的設定。

  6. 針對其他值,接受預設設定,然後選取 [ 新增]。

  7. [驗證] 頁面隨即開啟。 將 Microsoft Entra 應用程式的用戶端識別碼複製到 [記事本]。 您後續會用到此值。

    此螢幕擷取畫面有 [Microsoft Entra 設定] 視窗,其中顯示 Microsoft Entra 應用程式,以及 [Microsoft Entra 應用程式] 視窗,其中顯示要複製的用戶端識別碼。

如果您在這裡停止,您會有 App Service 驗證和授權保護的獨立式應用程式。 其餘各節說明如何將已驗證的使用者從前端傳遞至後端,以保護多個應用程式解決方案。

啟用前端應用程式的驗證和授權

  1. Azure 入口網站中,搜尋並選取 [資源群組]

  2. 在 [資源群組] 中,尋找並選取資源群組。 在 [ 概觀] 中,選取您的前端應用程式。

  3. 在前端應用程式的左側功能表中,選取 [ 設定>驗證],然後選取 [新增識別提供者]。

  4. 在 [ 新增識別提供者 ] 頁面中,針對 [ 識別提供者],選取 [Microsoft 以使用 Microsoft 和 Microsoft Entra 身分識別登入。

  5. 選取 [客戶端密碼到期] 的值。 針對其他值,接受預設設定,然後選取 [ 新增]。

  6. [驗證] 頁面隨即開啟。 將 Microsoft Entra 應用程式的用戶端識別碼複製到 [記事本]。 您後續會用到此值。

將前端應用程式存取權授與後端應用程式

您已啟用這兩個應用程式的驗證和授權。 若要完成驗證,您需要執行三個動作:

  • 藉由定義範圍,將後端應用程式公開為 API
  • 將前端應用程式存取權授與後端應用程式
  • 設定 App Service,以傳回可使用的權杖
  • 在您的程式代碼中使用令牌

備註

在您能授與前端應用程式存取後端之前,您必須先透過設定應用程式識別碼 URI 並定義至少一個範圍來公開後端 API。 這樣,在指派 API 權限時就可以在「我的 API」下選取後端。

秘訣

如果您遇到錯誤並重新設定應用程式的驗證/授權設定,令牌存放區中的令牌可能無法從新的設定重新產生。 若要確保您的令牌能重新生成,您需要先登出再重新登入您的應用程式。 其中一種方法是在私人模式中使用瀏覽器。 在變更應用程式中的設定後,關閉並重新以隱私模式開啟瀏覽器。

在本節中,您會代表使用者將後端應用程式的存取權授與前端應用程式。 技術上,您會為前端的 AD 應用程式 提供代表使用者存取後端 AD 應用程式 的許可權。

  1. 在前端應用程式的 [ 驗證 ] 頁面中,於 [ 識別提供者] 底下,選取您的前端應用程式名稱。 此應用程式註冊已自動為您生成。

  2. 選取左側功能表中的 [管理>API 許可權 ]。

  3. 選取 [新增權限],然後選取 [我的 API]>[後端應用程式名稱]<>

  4. 在後端應用程式的 [ 要求 API 許可權 ] 頁面中,選取 [委派的許可權 ] 並 user_impersonation,然後選取 [ 新增許可權]。

    [要求 API 權限] 頁面的螢幕擷取畫面,其中顯示已選取 [委派的權限]、[user_impersonation] 和 [新增權限] 按鈕。

設定 App Service 以返回可用的存取憑證

前端應用程式現在具有以登入使用者身分存取後端應用程式的必要許可權。 在本節中,設定 App Service 驗證和授權,以提供可供存取後端的存取令牌。 在此步驟中,您需要後端的用戶端識別碼,而此標識碼是從 啟用後端應用程式的驗證和授權複製而來。

在 Cloud Shell 中,在前端應用程式上執行下列命令,將 參數新增 scope 至驗證設定 identityProviders.azureActiveDirectory.login.loginParameters。 取代 <front-end-app-name><back-end-client-id>

az extension add --name authV2
authSettings=$(az webapp auth show -g myAuthResourceGroup -n <front-end-app-name>)
authSettings=$(echo "$authSettings" | jq '.properties' | jq '.identityProviders.azureActiveDirectory.login += {"loginParameters":["scope=openid offline_access api://<back-end-client-id>/user_impersonation"]}')
az webapp auth set --resource-group myAuthResourceGroup --name <front-end-app-name> --body "$authSettings"

命令會新增具有其他自定義範圍的 loginParameters 屬性。 以下是要求範圍的說明:

  • 預設情況下,App Service 會要求 openid。 如需詳細資訊,請參閱 OpenID Connect 範圍
  • 為了方便起見,這裡會包含offline_access,以防您想要重新整理令牌
  • api://<back-end-client-id>/user_impersonation 是後端應用程式註冊中公開的 API。 這是提供您 JWT 的範圍,其中包含後端應用程式作為權杖對象

秘訣

  • 若要在 Azure 入口網站中檢視 api://<back-end-client-id>/user_impersonation 範圍,請移至後端應用程式的 [ 驗證 ] 頁面,選取 [ 識別提供者] 底下的連結,然後選取左側功能表中的 [ 公開 API ]。
  • 若要改用 Web 介面設定必要的範圍,請參閱 重新整理驗證令牌
  • 部分範圍需要系統管理員或使用者同意。 當使用者在瀏覽器中登入前端應用程式時,此需求會導致同意要求頁面出現。 若要避免此同意頁面,請在 [ 公開 API ] 頁面中,將前端的應用程式註冊新增為已授權的用戶端應用程式。 選取 [新增用戶端應用程式 ],並提供前端應用程式註冊的用戶端標識符。

您的應用程式已完成設定。 前端現在已準備好使用適當的存取令牌來存取後端。

如需如何為其他提供者設定存取權杖的相關資訊,請參閱重新整理識別提供者權杖

設定後端 App Service 只接受來自前端 App Service 的令牌

您也應該將後端 App Service 設定為只接受來自前端 App Service 的令牌。 未執行此設定會導致當您將令牌從前端傳遞至後端時發生403禁止錯誤

您可以使用您在上一個步驟中使用的相同 Azure CLI 程式來實作此方法。

  1. 取得前端 App Service 的 appId。 您可以在前端 App Service 的 [ 驗證 ] 頁面上取得此值。

  2. 執行下列 Azure CLI,取代 <back-end-app-name><front-end-app-id>

authSettings=$(az webapp auth show -g myAuthResourceGroup -n <back-end-app-name>)
authSettings=$(echo "$authSettings" | jq '.properties' | jq '.identityProviders.azureActiveDirectory.validation.defaultAuthorizationPolicy.allowedApplications += ["<front-end-app-id>"]')
az webapp auth set --resource-group myAuthResourceGroup --name <back-end-app-name> --body "$authSettings"

前端會呼叫已驗證的後端

前端應用程式必須以正確的 user_impersonation 範圍將使用者的驗證傳遞至後端。 下列步驟會檢閱此功能範例中提供的程式碼。

檢視前端應用程式的原始碼:

  1. 使用前端的 App Service 注入的 x-ms-token-aad-access-token 標頭,程式化地取得使用者的存取權杖。

    // ./src/server.js
    const accessToken = req.headers['x-ms-token-aad-access-token'];
    
  2. 使用 Authentication 標頭中的 accessToken 作為 bearerToken 值。

    // ./src/remoteProfile.js
    // Get profile from backend
    const response = await fetch(remoteUrl, {
        cache: "no-store", // no caching -- for demo purposes only
        method: 'GET',
        headers: {
            'Authorization': `Bearer ${accessToken}`
        }
    });
    if (response.ok) {
        const { profile } = await response.json();
        console.log(`profile: ${profile}`);
    } else {
        // error handling
    }
    

    本教學課程會傳回偽造的設定檔,以簡化案例。 本系列中的下一個教學課程示範如何使用 Microsoft Graph 等下游 Azure 服務的範圍,交換後端 bearerToken 以取得新權杖。

後端會將個人資料傳回前端

如果前端的要求未獲得授權,後端 App Service 會在要求到達您的應用程式程式代碼 之前 ,以 401 HTTP 錯誤碼拒絕要求。 到達後端程式碼時,因為其包含授權的權杖,所以請擷取 bearerToken 以取得 accessToken

檢視後端應用程式的原始碼:

// ./src/server.js
const bearerToken = req.headers['Authorization'] || req.headers['authorization'];

if (bearerToken) {
    const accessToken = bearerToken.split(' ')[1];
    console.log(`backend server.js accessToken: ${!!accessToken ? 'found' : 'not found'}`);

    // TODO: get profile from Graph API
    // provided in next article in this series
    // return await getProfileFromMicrosoftGraph(accessToken)

    // return fake profile for this tutorial
    return {
        "displayName": "John Doe",
        "withAuthentication": !!accessToken ? true : false
    }
}

進入應用程式

  1. 在瀏覽器中使用前端網站。 URL 是 https://<front-end-app-name>.azurewebsites.net/

  2. 瀏覽器向 Web 應用程式要求驗證。 完成驗證。

    瀏覽器驗證快顯要求許可權的螢幕快照。

  3. 驗證完成之後,前端應用程式會傳回應用程式的首頁。

    Web 瀏覽器的螢幕快照,其中顯示成功完成驗證之後的前端應用程式。

  4. 選取 取得使用者資料。 此操作會將持有者令牌中的驗證資訊傳送至後端。

  5. 後端會以偽造的硬式編碼設定檔名稱回應:John Doe

    網頁瀏覽器的螢幕擷取畫面,其中顯示成功從後端應用程式取得偽造設定檔後的前端應用程式。

    withAuthentication true 的值表示現在已設定驗證。

清理資源

在上述步驟中,您已建立資源群組中的 Azure 資源。

  1. 在 Cloud Shell 中執行下列命令,以刪除資源群組。 此命令可能會花一分鐘執行。

    az group delete --name myAuthResourceGroup
    
  2. 在後端和前端應用程式的 區段中使用您先前找到並記下的驗證應用程式Enable authentication and authorization

  3. 刪除前端和後端應用程式的應用程式註冊。

    # delete app - do this for both frontend and backend client ids
    az ad app delete <client-id>
    

常見問題集

如何在本機開發電腦上測試此驗證?

此程序中的驗證是由 Azure App Service 在裝載平台層提供。 沒有對等的模擬器。 您必須部署前端和後端應用程式,併為每個應用程式設定驗證以使用驗證。

應用程式未顯示偽造的設定檔,如何偵錯?

當此應用程式未傳回/debug配置檔時,前端和後端應用程式都有路由來協助偵錯驗證。 前端偵錯路由提供要驗證的重要部分:

  • 環境變數:

    • BACKEND_URL 已正確設定為 https://<back-end-app-name>.azurewebsites.net。 請勿包含尾端正斜線或路由。
  • HTTP 標頭:

    • 插入 x-ms-token-* 標頭。
  • 顯示已登入使用者的 Microsoft Graph 設定檔名稱。

  • 權杖的前端應用程式範圍具有 user_impersonation。 如果您的範圍未包含此值,可能是計時問題。 在 login中確認前端應用程式的參數。 等候幾分鐘時間,讓驗證複寫。

應用程式原始程式碼是否已正確部署到每個 Web 應用程式?

  1. 在 Web 應用程式的 Azure 入口網站中,選取 [開發工具>],然後選取 [移至]。 此動作會開啟新的瀏覽器索引標籤或視窗。

  2. 在新的瀏覽器索引標籤中,選取 [瀏覽目錄>網站 wwwroot]。

  3. 驗證目錄中有下列項目:

    • package.json
    • node_modules.tar.gz
    • /src/index.js
  4. 確認 package.jsonname 屬性與 Web 名稱相同,或 frontendbackend

  5. 如果您變更了原始程式碼,而且需要重新部署,請在具有該應用程式 package.json 檔案的目錄中使用 az webapp up 命令。

應用程式是否已正確啟動?

當要求首頁時,這兩個 Web 應用程式都應該傳回一些內容。 如果您無法在 Web 應用程式上連線 /debug,則應用程式未正確啟動。 檢閱該 Web 應用程式的錯誤記錄檔。

  1. 在 Web 應用程式的 Azure 入口網站中,選取 [開發工具>],然後選取 [移至]。 此動作會開啟新的瀏覽器索引標籤或視窗。
  2. 在新的瀏覽器索引標籤中,選取 [瀏覽目錄>部署記錄]。
  3. 檢閱每個記錄檔,以找出任何回報的問題。

前端應用程式是否能夠與後端應用程式交談?

因為前端應用程式會從伺服器原始程式碼呼叫後端應用程式,因此此行為不是您在瀏覽器網路流量中看到的。 使用下列清單來判斷後端配置文件請求是否成功:

  • 如果到達後端 Web 應用程式,後端 Web 應用程式會將任何錯誤傳回至前端應用程式。 如果尚未連線到,前端應用程式會報告狀態代碼和訊息。

    • 401:使用者未正確傳遞驗證。 此訊息可能表示範圍未正確設定。
    • 404:伺服器的 URL 未符合伺服器擁有的路由
  • 當您提出使用者設定檔的前端要求時,請使用後端應用程式的串流記錄來監看。 原始程式碼中有偵錯資訊console.log,可協助確定故障發生的位置。

前端令牌到期時會發生什麼事?

存取權杖會在一段時間後到期。 若要了解如何重新整理存取權杖,而不需要讓使用者向應用程式重新驗證,請參閱重新整理識別提供者權杖

如果我在前端應用程式中有瀏覽器型應用程式,是否可以直接與後端通訊?

此方法需要伺服器程式代碼,才能將存取令牌傳遞至用戶端瀏覽器中執行的 JavaScript 程式代碼。 由於無法保護瀏覽器中的存取令牌,因此不建議使用此方法。 目前,我們建議 使用 Backend-for-Frontend 模式

如果套用至本教學課程中的範例,前端應用程式上的瀏覽器程式碼會在已驗證的工作階段中對其伺服器程式碼進行 API 呼叫做為中繼。 前端應用程式上的伺服器程式代碼接著會使用 x-ms-token-aad-access-token 標頭值作為持有人令牌,對後端應用程式進行 API 呼叫。 從瀏覽器程式代碼到伺服器程式代碼的所有呼叫都會受到已驗證會話的保護。

後續步驟

前往下一個教學課程,了解如何使用此使用者的身分識別來存取 Azure 服務。