基本 Web 應用程式

App Service
Key Vault
監視器
SQL Database
Web Apps

針對使用 Azure App ServiceAzure SQL Database,此參考架構會示範經過證實的作法。This reference architecture shows proven practices for a web application that uses Azure App Service and Azure SQL Database.

Azure 中基本 Web 應用程式的參考架構

下載這個架構的 Visio 檔案Download a Visio file of this architecture.

參考部署Reference deployment

此架構包括 Azure App Service 方案和空白應用程式、Azure SQL Database、用於儲存資料庫連接字串的 Azure Key Vault,以及用來進行記錄、監視和警示的 Azure 監視器。This architecture includes an Azure App Service plan and an empty application, Azure SQL Database, Azure Key Vault for storing the database connection string, and Azure Monitor for logging, monitoring, and alerting.

使用下列命令來建立部署的資源群組。Use the following command to create a resource group for the deployment. 按一下 [ 試試看 ] 按鈕,使用內嵌的 shell。Click the Try it button to use an embedded shell.

az group create --name basic-web-app --location eastus

執行下列命令,以部署 web 應用程式和支援的基礎結構。Run the following command to deploy the web application and supporting infrastructure. 出現提示時,請輸入使用者名稱和密碼。When prompted, enter a user name and password. 這些值是用來存取 Azure SQL Database 實例。These values are used for accessing the Azure SQL Database instance.

az deployment group create --resource-group basic-web-app  \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/basic-web-app/azuredeploy.json

如需詳細資訊和其他部署選項,請參閱用來部署此解決方案的 ARM 範本。For detailed information and additional deployment options, see the ARM Templates used to deploy this solution.

架構Architecture

此架構由下列元件組成。The architecture consists of the following components.

App service 方案app service 方案 提供受管理的虛擬機器 (vm) 裝載您的應用程式。App Service plan: An App Service plan provides the managed virtual machines (VMs) that host your app. 所有與方案相關聯的應用程式都會在相同的虛擬機器執行個體上執行。All apps associated with a plan run on the same VM instances.

App service 應用程式Azure app service 是完全受控的平臺,可用於建立及部署雲端應用程式。App Service app: Azure App Service is a fully managed platform for creating and deploying cloud applications.

部署 位置: 部署 位置可讓您暫存部署,然後將它與生產部署交換。Deployment slots: A deployment slot lets you stage a deployment and then swap it with the production deployment. 這樣一來,您可以避免直接在生產環境中部署。That way, you avoid deploying directly into production. 如需特定建議事項,請參閱可管理性一節。See the Manageability section for specific recommendations.

IP 位址: app Service 應用程式具有公用 IP 位址和功能變數名稱。IP address: The App Service app has a public IP address and a domain name. 網域名稱是 azurewebsites.net 的子網域,例如 contoso.azurewebsites.netThe domain name is a subdomain of azurewebsites.net, such as contoso.azurewebsites.net.

AZURE dnsAZURE dns 是 dns 網域的主機服務,使用 Microsoft Azure 基礎結構提供名稱解析。Azure DNS: Azure DNS is a hosting service for DNS domains, providing name resolution using Microsoft Azure infrastructure. 只要將您的網域裝載於 Azure,就可以像管理其他 Azure 服務一樣,使用相同的認證、API、工具和計費方式來管理 DNS 記錄。By hosting your domains in Azure, you can manage your DNS records using the same credentials, APIs, tools, and billing as your other Azure services. 若要使用自訂網域名稱 (例如 contoso.com),請建立 DNS 記錄,將自訂網域名稱對應至 IP 位址。To use a custom domain name (such as contoso.com) create DNS records that map the custom domain name to the IP address. 如需詳細資訊,請參閱 在 Azure App Service 中設定自訂網域名稱For more information, see Configure a custom domain name in Azure App Service.

AZURE Sql databasesql database 是雲端中的關係資料庫即服務。Azure SQL Database: SQL Database is a relational database-as-a-service in the cloud. SQL Database 與 Microsoft SQL Server 資料庫引擎共用其程式碼基底。SQL Database shares its code base with the Microsoft SQL Server database engine. 根據您的應用程式需求而定,您也可以使用適用於 MySQL 的 Azure 資料庫適用於 PostgreSQL 的 Azure 資料庫Depending on your application requirements, you can also use Azure Database for MySQL or Azure Database for PostgreSQL. 這些都是以開放原始碼 MySQL 伺服器和 Postgres 資料庫引擎為基礎的完全受控資料庫服務。These are fully managed database services based on the open-source MySQL Server and Postgres database engines.

建議Recommendations

您的需求可能和此處所述的架構不同。Your requirements might differ from the architecture described here. 以本節的建議作為起點。Use the recommendations in this section as a starting point.

App Service 方案App Service plan

基於測試目的,請使用 免費共用 (預覽版) 層,因為共用資源無法相應放大。這兩個層級會在您的預算內提供不同的選項。Use Free and Shared (preview) tiers for testing purposes because the shared resources cannot scale-out. The two tiers provide different options within your budget. 基本標準****和進 階層中執行生產工作負載,因為應用程式會在專用虛擬機器實例上執行,並已配置可相應放大的資源。App Service 方案會以每秒為單位計費。Run your production workload on Basic, Standard, and Premium tiers because the app runs on dedicated virtual machine instances and has allocated resources that can scale out. App Service plans are billed on a per-second basis.

如需詳細資訊,請參閱 我的 App Service 方案成本有多高?For more information, see How much does my App Service plan cost?

使用標準層或進階層,因為它們支援相應放大、自動調整和安全通訊端層 (SSL) 。Use the Standard or Premium tiers because they support scale-out, autoscale, and secure sockets layer (SSL). 每一層都支援數個不同于核心和記憶體數目的 實例大小Each tier supports several instance sizes that differ by the number of cores and memory. 建立方案之後,您可以變更服務層或執行個體的大小。You can change the tier or instance size after you create a plan. 如需 App Service 方案的詳細資訊,請參閱 App Service 價格For more information about App Service plans, see App Service Pricing.

您必須支付 App Service 方案中的執行個體費用,即使該應用程式已停用。You are charged for the instances in the App Service plan, even if the app is stopped. 請務必刪除您不使用的方案 (例如測試部署所使用的方案)。Make sure to delete plans that you aren't using (for example, test deployments).

SQL DatabaseSQL Database

邏輯伺服器群組可讓系統管理工作變得簡單。A logical server group makes administrative tasks simple. 群組中的每個資料庫都會使用特定的 服務層級進行部署。Each database within the group is deployed with a specific service tier. 在每個群組內,資料庫無法共用資源。Within each group, the databases cannot share resources. 伺服器沒有計算成本,但您必須指定每個資料庫的層級。There are no compute costs for the server, but you need to specify the tier for each database. 因此,效能可能會因為專用資源而更好,但成本可能較高。Therefore, the performance might be better because of the dedicated resources, but the cost can be higher.

使用 SQL Database V12 版Use the V12 version of SQL Database. SQL Database 支援基本、標準和進階服務層級,且各層內皆有多個以資料庫交易單位 (DTU) 計量的效能層級。SQL Database supports Basic, Standard, and Premium service tiers, with multiple performance levels within each tier measured in Database Transaction Units (DTUs). 進行容量規劃,然後選擇符合您需求的層和效能層級。Perform capacity planning and choose a tier and performance level that meets your requirements.

區域Region

將 App Service 方案和 SQL Database 佈建於相同區域,可使網路延遲降至最低。Provision the App Service plan and the SQL Database in the same region to minimize network latency. 通常會選擇最接近使用者的區域。Generally, choose the region closest to your users.

資源群組也會有區域,該區域會指定儲存部署中繼資料的位置。The resource group also has a region, which specifies where deployment metadata is stored. 將資源群組及其資源放置於相同區域。Put the resource group and its resources in the same region. 這麼做可在部署期間提升可用性。This can improve availability during deployment.

使用 定價計算機 來預估成本。Use the pricing calculator to estimate costs.

如需詳細資訊,請參閱 Microsoft Azure Well-Architected Framework 中的成本一節。For more information, see the cost section in Microsoft Azure Well-Architected Framework.

延展性考量Scalability considerations

Azure App Service 的主要優點是能夠根據負載調整應用程式規模。A major benefit of Azure App Service is the ability to scale your application based on load. 以下是規劃調整應用程式時,應記住的一些考量。Here are some considerations to keep in mind when planning to scale your application.

調整 App Service 應用程式的規模Scaling the App Service app

有兩種方式可用來調整 App Service 應用程式的規模:There are two ways to scale an App Service app:

  • 相應增加,表示變更執行個體的大小。Scale up, which means changing the instance size. 執行個體大小會決定每個虛擬機器執行個體上的記憶體、核心數及儲存體。The instance size determines the memory, number of cores, and storage on each VM instance. 您可以手動變更執行個體大小或方案層,來進行相應增加。You can scale up manually by changing the instance size or the plan tier.

  • 相應放大,表示新增執行個體以處理增加的負載。Scale out, which means adding instances to handle increased load. 每個定價層都有執行個體的數目上限。Each pricing tier has a maximum number of instances.

您可以藉由變更實例計數來手動相應放大, 或使用自動 調整來讓 Azure 根據排程和/或效能計量自動新增或移除實例。You can scale out manually by changing the instance count or use autoscaling to have Azure automatically add or remove instances based on a schedule and/or performance metrics. 每個調整規模作業會快速執行,通常在幾秒內。Each scale operation happens quickly, typically within seconds.

若要啟用自動調整,請建立自動調整設定檔,其中會定義執行個體數量的下限和上限。To enable autoscaling, create an autoscale profile that defines the minimum and maximum number of instances. 您可以建立排程設定。Profiles can be scheduled. 例如,您可以針對工作日和週末各別建立設定檔。For example, you might create separate profiles for weekdays and weekends. 設定檔可包含何時新增或移除執行個體的規則 (選擇性)。Optionally, a profile contains rules for when to add or remove instances. (例如:如果 CPU 使用量超過 70% 達 5 分鐘之久,則新增兩個執行個體。)(Example: Add two instances if CPU usage is above 70% for 5 minutes.)

調整 Web 應用程式規模的建議事項:Recommendations for scaling a web app:

  • 盡可能避免相應增加和減少,因為它可能會觸發應用程式重新開機。As much as possible, avoid scaling up and down because it may trigger an application restart. 相反地,在一般負載情況下請選擇符合您效能需求的層級和大小,然後相應放大執行個體來處理流量的變化。Instead, select a tier and size that meet your performance requirements under typical load and then scale out the instances to handle changes in traffic volume.
  • 啟用自動調整。Enable autoscaling. 如果您的應用程式具有可預測的工作負載規律性,則可建立設定檔以預先排定執行個體計數。If your application has a predictable, regular workload, create profiles to schedule the instance counts ahead of time. 如果工作負載不可預測,則可以設定規則來自動調整來因應負載的變更。If the workload is not predictable, use rule-based autoscaling to react to changes in load as they occur. 您可以結合這兩種方法。You can combine both approaches.
  • CPU 使用率通常是評估自動縮放規則的良好指標。CPU usage is generally a good metric for autoscale rules. 不過,您應對您的應用程式進行負載測試,找出潛在的瓶頸,並根據該資料設定自動調整規則。However, you should load test your application, identify potential bottlenecks, and base your autoscale rules on that data.
  • 自動調整規則包含 冷卻 期間,這是在開始新的調整動作之前,調整動作完成後等候的間隔。Autoscale rules include a cool-down period, which is the interval to wait after a scale action has been completed before starting a new scale action. 冷卻期間會讓系統穩定後,才能再次進行調整。The cool-down period lets the system stabilize before scaling again. 設定較短的冷卻時間,以新增實例和較長的冷卻期間來移除實例。Set a shorter cool-down period for adding instances and a longer cool-down period for removing instances. 例如,為新增執行個體設定 5 分鐘,但為移除執行個體設定 60 分鐘。For example, set 5 minutes to add an instance, but 60 minutes to remove an instance. 最好在繁重的負載下快速新增新的實例,以處理額外的流量,然後逐漸向後調整。It's better to add new instances quickly under heavy load to handle the additional traffic and then gradually scale back.

調整 SQL Database 的規模Scaling SQL Database

如果您的 SQL Database 需要較高服務層級或效能層級,您可以相應增加個別資料庫,且無須停止應用程式。If you need a higher service tier or performance level for SQL Database, you can scale up individual databases with no application downtime. 如需詳細資訊,請參閱 在 AZURE SQL database 中調整單一資料庫資源For more information, see Scale single database resources in Azure SQL Database.

可用性考量Availability considerations

在撰寫本文時,App Service 的服務等級協定 (SLA) 為99.95%,而 SQL Database 的 SLA 為適用于基本、標準和進階層的99.99%。At the time of writing, the service level agreement (SLA) for App Service is 99.95%, and the SLA for SQL Database is 99.99% for Basic, Standard, and Premium tiers. App Service SLA 適用於單一和多重執行個體。The App Service SLA applies to both single and multiple instances.

備份Backups

如果發生資料遺失,SQL Database 會提供還原時間點和異地還原。In the event of data loss, SQL Database provides point-in-time restore and geo-restore. 這些功能適用於所有層級,而且會自動啟用。These features are available in all tiers and are automatically enabled. 您不需要排程或管理備份。You don't need to schedule or manage the backups.

如需詳細資訊,請參閱 雲端商務持續性和 SQL Database 的資料庫災害復原For more information, see Cloud business continuity and database disaster recovery with SQL Database.

App Service 提供備份和還原應用程式檔案的功能。App Service provides a backup and restore feature for your application files. 不過,請注意,備份檔案包含純文字的應用程式設定,這些設定可能包含秘密,例如連接字串。However, be aware that the backed-up files include app settings in plain text, and these may include secrets, such as connection strings. 請避免使用 App Service 備份功能來備份您的 SQL 資料庫,因為它會將資料庫匯出至 SQL BACPAC 檔案,並耗用 dtuAvoid using the App Service backup feature to back up your SQL databases because it exports the database to a SQL BACPAC file, consuming DTUs. 請改用上述的 SQL Database 還原時間點。Instead, use SQL Database point-in-time restore described above.

管理性考量Manageability considerations

針對生產、部署和測試環境,各別建立資源群組。Create separate resource groups for production, development, and test environments. 這可讓您更輕鬆地管理部署、刪除測試部署及指派存取權限。This makes it easier to manage deployments, delete test deployments, and assign access rights.

將資源指派給資源群組時,請考慮下列項目:When assigning resources to resource groups, consider the following:

  • 生命週期。Lifecycle. 一般來說,會將生命週期相同的資源放在同個資源群組中。In general, put resources with the same lifecycle into the same resource group.
  • 存取。Access. 您可以使用 azure 角色型存取控制 (AZURE RBAC) 將存取原則套用至群組中的資源。You can use Azure role-based access control (Azure RBAC) to apply access policies to the resources in a group.
  • 計費。Billing. 您可以檢視資源群組的彙總成本。You can view the rolled-up costs for the resource group.

如需詳細資訊,請參閱 Azure Resource Manager 概觀For more information, see Azure Resource Manager overview.

DevOps 考量DevOps considerations

在此架構中,您會使用 Azure Resource Manager 範本 來布建 azure 資源及其相依性。In this architecture, you use an Azure Resource Manager template for provisioning the Azure resources and their dependencies. 由於這是單一 web 應用程式,因此,所有資源都會在相同的基本工作負載中隔離,讓您更輕鬆地將工作負載的特定資源關聯至小組,讓小組可以獨立管理這些資源的所有層面。Since this is a single web application, all the resources are isolated in the same basic workload, making it easier to associate the workload's specific resources to a team so that the team can independently manage all aspects of those resources. 這種隔離可讓 DevOps 團隊 (CI/CD) 執行持續整合和持續傳遞。This isolation enables the DevOps team to perform continuous integration and continuous delivery (CI/CD). 您也可以使用不同的 ARM 範本,並將它們與 Azure DevOps Services 整合,以在幾分鐘內布建不同的環境(例如,只在需要時才複寫類似生產的案例或負載測試環境)來節省成本。You can also use different ARM Templates and integrate them with Azure DevOps Services to provision different environments in minutes, for example, to replicate production-like scenarios or load testing environments only when needed, saving cost.

布建 web 應用程式的多個實例,因此它不會相依于單一實例,這可能會建立單一失敗點。Provision multiple instances of the web application, so it does not depend on a single instance, which could create a single point of failure. 此外,多個實例也可改善復原能力和擴充性。Also, multiple instances improve resiliency and scalability.

部署Deployment

部署包含兩個步驟:Deployment involves two steps:

  1. 佈建 Azure 資源。Provisioning the Azure resources. 對於此步驟,我們建議您使用 Azure Resoure Manager 範本We recommend that you use Azure Resource Manager templates for this step. 範本可讓您透過 PowerShell 或 Azure CLI,更輕鬆地自動執行部署。Templates make it easier to automate deployments via PowerShell or the Azure CLI.
  2. 部署應用程式 (程式碼、二進位檔和內容檔案)。Deploying the application (code, binaries, and content files). 您有多個選擇,包括從本機 Git 存放庫進行部署、使用 Visual Studio 或從雲端式原始檔控制進行連續部署。You have several options, including deploying from a local Git repository, using Visual Studio, or continuous deployment from cloud-based source control. 請參閱將您的應用程式部署至 Azure App ServiceSee Deploy your app to Azure App Service.

App Service 應用程式一律會有一個名為 production 的部署位置,代表實際作用的生產網站。An App Service app always has one deployment slot named production, which represents the live production site. 我們建議您為部署更新建立預備位置。We recommend creating a staging slot for deploying updates. 使用預備位置的優點包括:The benefits of using a staging slot include:

  • 您可以先確認部署是否成功,再將它交換至生產環境。You can verify the deployment succeeded before swapping it into production.
  • 部署至預備位置,可確保所有執行個體在交換至生產環境之前就已準備就緒。Deploying to a staging slot ensures that all instances are warmed up before being swapped into production. 許多應用程式都有重要的暖機和冷啟動時間。Many applications have a significant warmup and cold-start time.

我們也建議您建立第三個位置來保存上一次的正確部署。We also recommend creating a third slot to hold the last-known-good deployment. 當您交換預備環境和生產環境之後,請將先前的生產環境部署 (現在處於預備環境) 移到「上一次的正確部署」位置。After you swap staging and production, move the previous production deployment (which is now in staging) into the last-known-good slot. 這樣一來,如果您之後發現問題,您可以快速還原至上一次的正確版本。That way, if you discover a problem later, you can quickly revert to the last-known-good version.

交換生產和預備環境部署的位置

如果還原至之前的版本,請確定任何資料庫的結構描述變更都可以與舊版相容。If you revert to a previous version, make sure any database schema changes are backward compatible.

請勿使用生產環境部署上的位置進行測試,因為同個 App Service 方案內的所有應用程式會共用相同的虛擬機器執行個體。Don't use slots on your production deployment for testing because all apps within the same App Service plan share the same VM instances. 例如,負載測試可能會使實際作用的生產網站降級。For example, load tests might degrade the live production site. 針對生產和測試,請建立不同的 App Service 方案。Instead, create separate App Service plans for production and test. 透過將測試部署放在不同方案內,您可以使其與生產版本隔離。By putting test deployments into a separate plan, you isolate them from the production version.

組態Configuration

儲存作為應用程式設定的組態設定。Store configuration settings as app settings. 在您的 Resource Manager 範本中或使用 PowerShell 定義應用程式設定。Define the app settings in your Resource Manager templates or using PowerShell. 在執行階段上,應用程式設定可作為應用程式的環境變數。At runtime, app settings are available to the application as environment variables.

永遠不要將密碼、存取金鑰或連接字串簽入原始檔控制。Never check passwords, access keys, or connection strings into source control. 而是會將這些項目作為參數傳遞給部署指令碼,將這些值儲存至應用程式設定。Instead, pass these as parameters to a deployment script that stores these values as app settings.

依預設,當您交換部署位置時,應用程式設定也會進行交換。When you swap a deployment slot, the app settings are swapped by default. 如果您需要不同的生產和預備設定,您可以建立可移至某個位置且未交換的應用程式設定。If you need different production and staging settings, you can create app settings that stick to a slot and don't get swapped.

診斷和監控Diagnostics and monitoring

啟用 診斷記錄,包括應用程式記錄和 web 伺服器記錄。Enable diagnostics logging, including application logging and web server logging. 設定記錄以使用 Azure Log Analytics。Configure logging to use Azure Log Analytics. 如需記錄的詳細指引,請參閱監視和診斷指引For more detailed guidance on logging, see Monitoring and diagnostics guidance.

使用 New RelicApplication Insights 來監視負載下的應用程式效能和行為。Use a service such as New Relic or Application Insights to monitor application performance and behavior under load. 請留意 Application insights 的資料速率限制Be aware of the data rate limits for Application Insights.

使用 Azure DevOpsVisual Studio Team Foundation Server 等工具執行負載測試。Perform load testing, using a tool such as Azure DevOps or Visual Studio Team Foundation Server. 如需雲端應用程式中的一般效能分析概觀,請參閱效能分析入門For a general overview of performance analysis in cloud applications, see Performance Analysis Primer.

針對應用程式進行疑難排解的秘訣:Tips for troubleshooting your application:

如需詳細資訊,請參閱 Azure Well-Architected Framework中的 DevOps 一節。For more information, see the DevOps section in Azure Well-Architected Framework.

安全性考量Security considerations

本節列出 Azure 服務專屬的安全性考量,This section lists security considerations that are specific to the Azure services described in this article. 但不是安全性最佳做法的完整清單。It's not a complete list of security best practices. 如需更多的安全性考量,請參閱保護 Azure App Service 中的應用程式For some additional security considerations, see Secure an app in Azure App Service.

SQL Database 稽核SQL Database auditing

稽核可協助您保持法規遵循,以及深入了解可指出商務考量或疑似安全違規的不一致和不合規行為。Auditing can help you maintain regulatory compliance and get insight into discrepancies and irregularities that could indicate business concerns or suspected security violations. 請參閱開始使用 SQL Database 稽核See Get started with SQL database auditing.

部署位置Deployment slots

每個部署位置都具有公用 IP 位址。Each deployment slot has a public IP address. 使用 Azure Active Directory 登入可保護非生產位置,因此只有您的開發和 DevOps 小組成員可以連線至這些端點。Secure the nonproduction slots using Azure Active Directory login so that only members of your development and DevOps teams can reach those endpoints.

記錄Logging

記錄絕對不能記下使用者的密碼,或其他可能可用來認可身分識別詐騙的資訊。Logs should never record users' passwords or other information that might be used to commit identity fraud. 儲存之前請先從資料中清除這些細節。Scrub those details from the data before storing it.

SSLSSL

App Service 應用程式包含 azurewebsites.net 子網域的 SSL 端點 (不需額外費用)。An App Service app includes an SSL endpoint on a subdomain of azurewebsites.net at no additional cost. SSL 端點包含 *.azurewebsites.net 網域的萬用字元憑證。The SSL endpoint includes a wildcard certificate for the *.azurewebsites.net domain. 如果您使用自訂網域名稱,您必須提供符合自訂網域的憑證。If you use a custom domain name, you must provide a certificate that matches the custom domain. 最簡單的方式是直接透過 Azure 入口網站購買憑證。The simplest approach is to buy a certificate directly through the Azure portal. 您也可以從其他憑證授權單位匯入憑證。You can also import certificates from other certificate authorities. 如需詳細資訊,請參閱購買並設定您 Azure App Service 的 SSL 憑證For more information, see Buy and Configure an SSL Certificate for your Azure App Service.

作為最佳安全性做法,您的應用程式應該透過重新導向 HTTP 要求來強制執行 HTTPS。As a security best practice, your app should enforce HTTPS by redirecting HTTP requests. 您可以在您的應用程式中實作此項目,或如針對 Azure App Service 中的應用程式啟用 HTTPS中所述使用 URL 重寫規則。You can implement this inside your application or use a URL rewrite rule as described in Enable HTTPS for an app in Azure App Service.

驗證Authentication

我們建議您透過識別提供者 (IDP) 進行驗證,例如 Azure AD、Facebook、Google 或 Twitter。We recommend authenticating through an identity provider (IDP), such as Azure AD, Facebook, Google, or Twitter. 使用 OAuth 2 或 OpenID Connect (OIDC) 作為驗證流程。Use OAuth 2 or OpenID Connect (OIDC) for the authentication flow. Azure AD 提供的功能可管理使用者和群組、建立應用程式角色、整合您的內部部署身分識別,以及使用 Microsoft 365 和商務用 Skype 等後端服務。Azure AD provides functionality to manage users and groups, create application roles, integrate your on-premises identities, and consume backend services such as Microsoft 365 and Skype for Business.

應避免讓應用程式直接管理使用者登入和認證,因為應用程式會產生潛在的攻擊面。Avoid having the application manage user logins and credentials directly, as it creates a potential attack surface. 您至少需要有電子郵件確認、密碼復原和多重要素驗證、驗證密碼強度,以及安全地儲存密碼雜湊。At a minimum, you would need to have an email confirmation, password recovery, and multi-factor authentication, validate password strength, and store password hashes securely. 大型身分識別提供者會為您處理所有的專案,並持續監視並改善其安全性作法。The large identity providers handle all of those things for you and are constantly monitoring and improving their security practices.

請考慮使用 App Service 服務驗證來實作 OAuth/OIDC 驗證流程。Consider using App Service authentication to implement the OAuth/OIDC authentication flow. App Service 驗證的優點包括:The benefits of App Service authentication include:

  • 容易設定。Easy to configure.
  • 不需要撰寫程式碼即可使用的簡單驗證情境。No code is required for simple authentication scenarios.
  • 支援委派授權使用 OAuth 存取權杖來代表使用者使用資源。Supports delegated authorization using OAuth access tokens to consume resources on behalf of the user.
  • 提供內建權杖快取。Provides a built-in token cache.

App Service 驗證的部分限制:Some limitations of App Service authentication:

  • 限制的自訂選項。Limited customization options.
  • 委派授權僅限於每個登入工作階段的一個後端資源。Delegated authorization is restricted to one backend resource per login session.
  • 如果您使用多個 IDP,則沒有任何內建機制可用於首頁領域探索。If you use more than one IDP, there is no built-in mechanism for home realm discovery.
  • 在多租用戶的情況下,應用程式必須實作邏輯以驗證權杖簽發者。For multi-tenant scenarios, the application must implement the logic to validate the token issuer.