Azure App Service 和 Azure Functions 中的驗證和授權

Azure App Service 提供內建的驗證和授權功能, (有時稱為「簡單驗證」 ) ,因此您可以在 web 應用程式、RESTful API 和行動後端中撰寫最少量或無程式碼,以登入使用者並存取資料,同時 Azure Functions。 本文說明 App Service 如何協助您簡化應用程式的驗證和授權。

為何要使用內建驗證?

您不需要使用這項功能來進行驗證和授權。 您可以在您選擇的 web 架構中使用配套的安全性功能,也可以撰寫自己的公用程式。 不過,您必須使用最新的安全性、通訊協定和瀏覽器更新,確保您的解決方案保持最新狀態。

針對驗證 (登入使用者) 與授權 (提供安全) 資料存取的安全解決方案,可能會有很大的努力。 您必須確保遵循業界最佳作法和標準,並讓您的實施保持在最新狀態。 App Service 和 Azure Functions 的內建驗證功能,可讓您藉由提供與同盟身分識別提供者的現成驗證來節省您的時間和精力,讓您能夠專注于應用程式的其餘部分。

  • Azure App Service 可讓您將各種不同的驗證功能整合到您的 web 應用程式或 API,而不需要自行執行。
  • 它是直接內建在平臺中,不需要任何特定語言、SDK、安全性專業知識,甚至任何程式碼都可以使用。
  • 您可以與多個登入提供者整合。 例如,Azure AD、Facebook、Google、Twitter。

識別提供者

App Service 使用同盟身分識別,由第三方識別提供者為您管理使用者身分識別和驗證流程。 以下是預設可用的識別提供者:

提供者 登入端點 How-To 指導方針
Microsoft 身分識別平臺 /.auth/login/aad App Service Microsoft 身分識別平臺登入
Facebook /.auth/login/facebook App Service Facebook 登入
Google /.auth/login/google App Service Google 登入
Twitter /.auth/login/twitter App Service Twitter 登入
任何 OpenID Connect 提供者 (預覽) /.auth/login/<providerName> App Service OpenID Connect 登入

當您利用上述其中一個提供者啟用驗證和授權時,其登入端點即可用來驗證使用者,以及用來驗證提供者的驗證權杖。 您可以為您的使用者提供任意數目的登入選項。

使用內建驗證的考慮

啟用此功能將會自動將應用程式的所有要求重新導向至 HTTPS,不論 App Service 的設定設定是否強制使用 HTTPS。 您可以使用 V2 設定中的設定來停用此功能  requireHttps 。 不過,我們建議您不要使用 HTTPS,而且您應該確保任何安全性權杖都不會透過非安全的 HTTP 連線傳輸。

App Service 可以用來進行驗證,或不限制對您網站內容和 Api 的存取。 若要將應用程式存取限制為僅限已驗證的使用者,請設定 當要求未經驗證 ,以使用其中一個設定的身分識別提供者登入時,所要採取的動作。 若要驗證但不限制存取,請設定當要求未通過「允許匿名要求 (沒有動作) 」 驗證時所採取的動作

注意

您應該為每個應用程式註冊自己的許可權和同意。 對不同的部署位置使用不同的應用程式註冊,以避免在環境之間共用權限。 測試新的程式碼時,這種做法有助於避免問題影到響生產應用程式。

運作方式

Windows 上的功能架構 (非容器部署) )

Linux 和容器上的功能架構

驗證流程

授權行為

使用者和應用程式宣告

權杖存放區

記錄和追蹤

Windows 上的功能架構 (非容器部署)

驗證和授權模組會在與應用程式程式碼相同的沙箱中執行。 此模組啟用時,每個連入的 HTTP 要求會先通過此模組,再由應用程式程式碼處理。

此架構圖表顯示在網站沙箱中,與識別提供者互動的進程所攔截到的要求,然後允許流量傳送至部署的網站

此模組會處理應用程式的幾件事:

  • 向指定提供者驗證使用者
  • 驗證、儲存及重新整理權杖
  • 管理已驗證的工作階段
  • 將身分識別資訊插入要求標頭中

此模組會與應用程式程式碼分開執行,並且會使用應用程式設定加以設定。 不需要任何 SDK、特定語言或對應用程式程式碼進行任何變更。

Linux 和容器上的功能架構

驗證和授權模組會在個別的容器中執行,並與您的應用程式程式碼隔離。 使用所謂的 大使模式,它會與連入流量互動,以在 Windows 上執行類似的功能。 因為它不是以同進程執行,所以無法與特定語言架構進行直接整合;不過,您的應用程式所需的相關資訊會透過使用要求標頭來傳遞,如下所述。

驗證流程

所有提供者的驗證流程皆相同,但會根據您是否要使用提供者的 SDK 登入而有所不同:

  • 不使用提供者 SDK:應用程式會將同盟登入委派給 App Service。 瀏覽器應用程式通常是這種情況,可以向使用者顯示提供者的登入頁面。 伺服器程式碼會管理登入程序,因此也稱為「伺服器導向流程」或「伺服器流程」。 此案例適用於瀏覽器應用程式。 它也適用於使用 Mobile Apps 用戶端 SDK 將使用者登入的原生應用程式,因為 SDK 會開啟 Web 檢視,使用 App Service 驗證將使用者登入。
  • 使用提供者 SDK:應用程式會以手動方式將使用者登入提供者,然後將驗證權杖提交給 App Service 進行驗證。 無瀏覽器應用程式通常是這種情況,無法向使用者顯示提供者的登入頁面。 應用程式程式碼會管理登入程序,因此也稱為「用戶端導向流程」或「用戶端流程」。 此案例適用於 REST API、Azure Functions、JavaScript 瀏覽器用戶端,以及在登入程序中需要更多彈性的瀏覽器應用程式。 它也適用於使用提供者 SDK 將使用者登入的原生行動應用程式。

從 App Service 中受信任的瀏覽器應用程式呼叫 App Service 或 Azure Functions 中的另一個 REST API,可以使用伺服器導向的流程進行驗證。 如需詳細資訊,請參閱自訂 App Service 中的驗證與授權

下表顯示驗證流程的步驟。

步驟 不使用提供者 SDK 使用提供者 SDK
1. 登入使用者 將用戶端重新導向至 /.auth/login/<provider> 用戶端程式碼會直接使用提供者的 SDK 將使用者登入,並接收驗證權杖。 如需詳細資訊,請參閱提供者的文件。
2. 驗證後 提供者會將用戶端重新導向至 /.auth/login/<provider>/callback 用戶端程式代碼會將 來自提供者的 token 張貼 至以 /.auth/login/<provider> 進行驗證。
3. 建立已驗證的會話 App Service 會將已驗證的 Cookie 新增至回應。 App Service 會將自己的驗證權杖傳回至用戶端程式碼。
4. 為已驗證的內容提供服務 用戶端會在後續要求中包含驗證 Cookie (瀏覽器會自動處理)。 用戶端程式碼會在 X-ZUMO-AUTH 標頭中顯示驗證權杖 (Mobile Apps 用戶端 SDK 會自動處理)。

對於用戶端瀏覽器,App Service 可以自動將所有未經驗證的使用者導向至 /.auth/login/<provider>。 您也可以向使用者顯示一或多個 /.auth/login/<provider> 連結,讓其使用選擇的提供者登入您的應用程式。

授權行為

Azure 入口網站中,當連入要求未通過驗證時,您可以設定具有許多行為的 App Service。 下列標題會說明可用選項。

允許未經驗證的要求

此選項會將未經驗證的流量授權延遲至您的應用程式程式碼。 對於已驗證的要求,App Service 也會在 HTTP 標頭中一起傳送驗證資訊。

此選項會提供更大的彈性來處理匿名要求。 例如,它可讓您向使用者顯示多個登入提供者。 不過,您必須撰寫程式碼。

需要驗證

此選項會拒絕任何未經驗證的流量傳送至您的應用程式。 這項拒絕可以是其中一個已設定的身分識別提供者的重新導向動作。 在這些情況下,會將瀏覽器用戶端重新導向至 /.auth/login/<provider> 您所選擇的提供者。 如果匿名要求來自原生行動應用程式,則傳回的回應是 HTTP 401 Unauthorized。 您也可以將拒絕設定為 HTTP 401 UnauthorizedHTTP 403 Forbidden 所有要求。

使用此選項時,您不需要在應用程式中撰寫任何驗證程式碼。 您可以藉由檢查使用者的宣告來處理更精細的授權 (例如特定角色授權,請參閱存取使用者宣告)。

警告

以這種方式限制存取會套用至對您應用程式的所有呼叫,這對需要公開可用的首頁的應用程式可能不需要,如同許多單頁應用程式一樣。

注意

根據預設,Azure AD 租使用者中的任何使用者都可以從 Azure AD 要求您應用程式的權杖。 如果您想要將應用程式的存取許可權制為一組已定義的使用者,您可以 在 Azure AD 中設定應用程式

使用者和應用程式宣告

針對所有語言架構,App Service 會將內送權杖中的宣告 (,使其從已驗證的使用者或用戶端應用程式中,藉由將其插入要求標頭中,來) 可供您的程式碼使用。 在 ASP.NET 4.6 應用程式中,App Service 會使用已驗證的使用者宣告填入 ClaimsPrincipal.Current,因此您可以遵循標準的 .NET 程式碼模式,包括 [Authorize] 屬性。 同樣地,在 PHP 應用程式中,App Service 會填入 _SERVER['REMOTE_USER'] 變數。 對於 JAVA 應用程式, 可從 Tomcat servlet 存取宣告。

若為 Azure FunctionsClaimsPrincipal.Current 則不會針對 .net 程式碼填入,但您仍然可以在要求標頭中找到使用者宣告,或 ClaimsPrincipal 從要求內容或甚至透過系結參數取得物件。 如需詳細資訊,請參閱 使用用戶端 身分識別。

如需詳細資訊,請參閱存取使用者宣告

目前,ASP.NET Core 目前不支援使用驗證/授權功能來擴展目前的使用者。 不過,有一些 協力廠商的開放原始碼中介軟體元件 ,可協助填滿此間隙。

權杖存放區

App Service 會提供內建的權杖存放區,也就是與 Web 應用程式、API 或原生行動應用程式相關聯的權杖存放庫。 當您使用任何提供者啟用驗證時,此權杖存放區就會立即供應用程式使用。 如果應用程式程式碼需要代表使用者存取這些提供者的資料,例如:

  • 張貼至已驗證使用者的 Facebook 時間軸
  • 使用 Microsoft Graph API 來讀取使用者的公司資料

您通常必須撰寫程式碼,才能在應用程式中收集、儲存及重新整理這些權杖。 使用權杖存放區時,您只有在需要權杖時才會取出權杖,並在權杖失效時才會告知 App Service 加以重新整理

識別碼權杖、存取權杖和重新整理權杖會針對已驗證的會話進行快取,而且只能由相關聯的使用者存取。

如果您不需要在應用程式中使用權杖,可以在應用程式的 [ 驗證/授權 ] 頁面中停用權杖存放區。

記錄和追蹤

如果您啟用應用程式記錄,則會直接在記錄檔中看到驗證和授權追蹤。 如果您看到未預期的驗證錯誤,您可以查看現有的應用程式記錄檔,以輕鬆地找到所有詳細資料。 如果您啟用失敗要求追蹤,就可以看到驗證和授權模組可能在失敗要求中所扮演的確切角色。 在追蹤記錄中,尋找名為 EasyAuthModule_32/64 的模組參考。

其他資源

範例: