重新導向 URI (回覆 URL) 大綱和限制
若要登入使用者，您的應用程式必須將登入要求傳送至 Microsoft Entra 授權端點，並指定重新導向 URI 作為參數。 重新導向 URI 是重要的安全性功能，可確保 Microsoft Entra 驗證伺服器只會將授權碼和存取權杖傳送給預期的收件者。 本文概述 Microsoft 身分識別平台中重新導向 URI 的功能和限制。
何謂重新導向 URI？
重新導向 URI 或回覆 URL 是 Microsoft Entra 驗證伺服器成功授權並獲授與存取權杖後，傳送使用者的位置。 若要登入使用者，您的應用程式必須傳送具有指定為參數之重新導向 URI 的登入要求，以致使用者成功登入之後，驗證伺服器會將使用者重新導向，並將存取權杖發送至登入要求中指定的重新導向 URI。
為何需要將重新導向 URI 新增至應用程式註冊？
基於安全性考慮，驗證伺服器不會將使用者重新導向或將權杖傳送到未新增至應用程式註冊的 URI。 Microsoft Entra 登入伺服器只會將使用者重新導向，並將權杖傳送到已新增至應用程式註冊的 URI。 如果登入要求中指定的重新導向 URI 與您在應用程式中新增的任何重新導向 URI 均不相符，您會收到錯誤訊息，例如 AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application。
如需錯誤碼的詳細資訊，請參閱 Microsoft Entra 驗證和授權錯誤碼。
我應該將重新導向 URI 新增至應用程式註冊嗎？
您是否該將重新導向 URI 新增至應用程式註冊，取決於應用程式所使用的授權通訊協定。 如果您的應用程式使用下列授權通訊協定，則必須將正確的重新導向 URI 新增至應用程式註冊：
如果您的應用程式使用下列授權通訊協定或功能，則不需要將重新導向 URI 新增至應用程式註冊。
- 原生驗證
- OAuth 2.0 裝置程式碼流程
- OAuth 2.0 代理者流程
- OAuth 2.0 資源擁有者密碼認證流程
- Windows 整合式驗證流程
- SAML 2.0 識別提供者 (IdP) 進行單一登入
我應該將重新導向 URI 新增至哪個平台？
如果您要建置的應用程式在應用程式註冊中包含一或多個重新導向 URI，您必須啟用 公用用戶端流程組態。 下表提供您是否應該依據您要建置應用程式的平台新增重新導向 URI 類型的指引。
Web 應用程式重新導向 URI 組態
| 您的應用程式類型 | 一般語言/架構 | 在應用程式註冊中新增重新導向 URI 的平台 |
|---|---|---|
| 在伺服器上執行大部分應用程式邏輯的傳統 Web 應用程式 | Node.js、Web、ASP.NET、Python、JAVA、ASP.NET Core、PHP、Ruby、Blazor Server | Web |
| 單頁應用程式，其中大部分的使用者介面邏輯會在與 Web 伺服器通訊 (主要使用 Web API) 的網頁瀏覽器中執行 | JavaScript、Angular、React、Blazor WebAssembly、Vue.js | 單頁應用程式 (SPA) |
行動和傳統型應用程式重新導向 URI 設定
| 您的應用程式類型 | 一般語言/架構 | 在應用程式註冊中新增重新導向 URI 的平台 |
|---|---|---|
| iOS 或 macOS 應用程式，不包括下表所列的案例 | Swift、Objective-C、Xamarin | IOS/macOS |
| Android 應用程式 | Java、Kotlin、Xamarin | Android |
| 在行動裝置或桌面電腦上以原生方式執行的應用程式 | Node.js 電子、Windows 桌面、UWP、React Native、Xamarin、Android、iOS/macOS | 行動應用程式與傳統型應用程式 |
如果您要使用下列其中一種方法建置 iOS 應用程式，請使用「行動和傳統型應用程式」平台來新增重新導向 URI：
- 使用舊版 SDK 的 iOS 應用程式 (ADAL)
- 使用開放原始碼 SDK 的 iOS 應用程式 (AppAuth)
- 使用我們不支援的跨平台技術 (Flutter) 的 iOS 應用程式
- 直接實作 OAuth 通訊協定的 iOS 應用程式
- 使用我們不支援的跨平台技術 (Electron) 的 macOS 應用程式
不需要重新導向 URI 的應用程式
| 應用程式類型 | 範例/附註 | 相關聯的 OAuth 流程 |
|---|---|---|
| 在沒有鍵盤的裝置上執行的應用程式 | 在智慧型手機電視、IoT 裝置或印表機上執行的應用程式 | 裝置程式碼流程 深入瞭解 |
| 處理密碼使用者直接輸入的應用程式，而不是將使用者重新導向至 Entra 託管的登入網站，並讓 Entra 以安全的方式處理用戶密碼。 | 只有在授權碼流程等其他更安全的流程無法運作時，才應該使用此流程，因為它比較不安全。 | 資源擁有者密碼認證流程 深入瞭解 |
| 使用 Windows 整合式驗證流程而非 Web 帳戶管理員，在 Windows 或連線到 Windows 網域的電腦上執行桌面或行動應用程式 (AD 或已加入 Azure AD) | 使用者使用 Entra 認證登入 Windows 電腦系統之後，應該自動登入的桌面或行動應用程式 | Windows 整合式驗證流程 深入瞭解 |
Microsoft Entra 應用程式的重新導向 URI 有何限制？
Microsoft Entra 應用程式模型會指定下列對重新導向 URI 的限制：
重新導向 URI 的開頭必須是方案
https，但 不包括某些 localhost 的重新導向 URI重新導向 URI 會區分大小寫，且必須符合執行中應用程式的 URL 路徑大小寫。
範例：
- 如果您的應用程式在其路徑中包含了
.../abc/response-oidc，請勿在重新導向 URI 中指定.../ABC/response-oidc。 由於網頁瀏覽器會將路徑視為區分大小寫，因此，如果將與.../abc/response-oidc相關聯的 Cookie 重新導向至不相符的.../ABC/response-oidcURL，可能就會予以排除。
- 如果您的應用程式在其路徑中包含了
未設定路徑線段的重新導向 URI 會在回應中傳回結尾斜線 ('
/')。 這僅適用於回應模式為query或fragment時。範例：
https://contoso.com會以https://contoso.com/的形式傳回http://localhost:7071會以http://localhost:7071/的形式傳回
包含路徑線段的重新導向 URI 不會在回應中附加尾端斜線。
範例：
https://contoso.com/abc會以https://contoso.com/abc的形式傳回https://contoso.com/abc/response-oidc會以https://contoso.com/abc/response-oidc的形式傳回
重新導向 URI 不 支援特殊字元 -
! $ ' ( ) , ;重新導向URI 不支援國際化網域名稱
重新導向 URI 和 URI 長度上限
基於 安全性原因，重新導向 URI 的數目上限無法提高。 如果您案例需要的重新導向 URI 數目超過允許的上限，請考慮下列狀態參數方法來做為解決方案。 下表顯示您可以在 Microsoft 身分識別平台中新增至應用程式註冊的重新導向 URI 數目上限。
| 已登入的帳戶 | 重新導向 URI 數目的上限 | 描述 |
|---|---|---|
| 在任何組織的 Microsoft Entra 租用戶中Microsoft 的公司或學校帳戶 | 256 | 應用程式資訊清單中的 signInAudience 欄位會設定為 AzureADMyOrg 或 AzureADMultipleOrgs |
| 個人 Microsoft 帳戶及公司與學校帳戶 | 100 | 應用程式資訊清單中的 signInAudience 欄位會設定為 AzureADandPersonalMicrosoftAccount |
在您新增至應用程式註冊的每個重新導向 URI 上，您最多可以使用 256 個字元。
應用程式與服務主體物件中的重新導向 URI
- 一律 只把重新導向 URI 新增至應用程式物件。
- 絕不 將重新導向 URI 值新增至服務主體，因為當服務主體對象與應用程式物件同步時，可能會移除這些值。 這可能是因為觸發兩個物件之間同步處理的任何更新作業。
重新導向 URI 中的查詢參數支援
對於 只 使用公司或學校帳戶登入使用者的應用程式，重新導向 URI 中 允許 使用查詢參數。
任何設定為使用個人 Microsoft 帳戶登入使用者的應用程式註冊，例如 Outlook.com (Hotmail)、Messenger、OneDrive、MSN、Xbox Live 或 Microsoft 365，均 不允許 在重新導向 URI 中使用查詢參數。
| 應用程式註冊登入受眾 | 支援重新導向 URI 中的查詢參數 |
|---|---|
| 僅限此組織目錄中的帳戶 (僅限 Contoso - 單一租用戶) | 
|
| 任何組織目錄中的帳戶 (任何 Microsoft Entra 目錄 - 多組織用戶共享) |
|
| 任何組織目錄中的帳戶 (任何 Microsoft Entra 目錄 - 多租用戶) 和個人 Microsoft 帳戶 (例如 Skype 和 Xbox) | 
|
| 僅限個人 Microsoft 帳戶 |
|
支援的配置
HTTPS：所有以 HTTP 為基礎的重新導向 URI 都支援 HTTPS 配置 (https://)。
HTTP：只有 localhost URI 支援 HTTP 配置 (http://)，而且只能在作用中的本機應用程式開發和測試期間使用。
| 重新導向 URI 範例 | 有效期 |
|---|---|
https://contoso.com |
有效 |
https://contoso.com/abc/response-oidc |
有效 |
https://localhost |
有效 |
http://contoso.com/abc/response-oidc |
無效 |
http://localhost |
有效 |
http://localhost/abc |
有效 |
Localhost 例外狀況
根據 RFC 8252 的 8.3 節和 7.3 節，"loopback" 或 "localhost" 重新導向 URI 有兩個特殊考量：
httpURI 配置是可接受的，因為重新導向永遠不會離開裝置。 因此，這兩個 URI 都是可接受的：http://localhost/myApphttps://localhost/myApp
- 由於原生應用程式通常需要暫時的連接埠範圍，因此連接埠元件 (例如
:5001或:443) 會基於比對重新導向 URI 的目的而遭到忽略。 因此，以下這些 URI 都會視為相等的：http://localhost/MyApphttp://localhost:1234/MyApphttp://localhost:5000/MyApphttp://localhost:8080/MyApp
從開發的觀點來看，這代表了幾件事：
請勿註冊多個只有連接埠不同的重新導向 URI。 登入伺服器會任意挑選一個，並使用與該重新導向 URI 相關聯的行為 (例如，無論是
web-、native-或spa- 類型重新導向)。當您想要在相同的應用程式註冊中使用不同的驗證流程時 (例如授權碼授與和隱含流程)，這點特別重要。 若要將正確的回應行為與每個重新導向 URI 關聯，登入伺服器必須能夠區分重新導向 URI，而且如果只有連接埠不同，則無法這麼做。
若要在 localhost 上註冊多個重新導向 URI，以在開發期間測試不同的流程，請使用 URI 的路徑元件來進行區分。 例如，
http://localhost/MyWebApp不符合http://localhost/MyNativeApp。目前不支援 IPv6 迴路位址 (
[::1])。
使用 127.0.0.1 而非 localhost
若要防止您的應用程式因為防火牆設定錯誤或網路介面重新而中斷，請在重新導向 URI 中使用 IP 常值迴路位址 127.0.0.1 (而非 localhost)。 例如： https://127.0.0.1 。
不過，您無法使用 Azure 入口網站中的 [重新導向 URI] 文字輸入區域，以新增使用 http 方案的迴路式重新導向 URI：
若要新增使用 http 配置 127.0.0.1 搭配 loopback 位址的重新導向 URI，您目前必須修改應用程式資訊清單中的 replyUrlsWithType 屬性。
重新導向 URI 中的萬用字元限制
萬用字元 URI (例如 https://*.contoso.com) 似乎很方便，但由於安全性的影響，應避免使用。 根據 OAuth 2.0 規格 (RFC 6749 的第 3.1.2 節)，重新導向端點 URI 必須是絕對 URI。 因此，當設定的萬用字元 URI 與重新導向 URI 相符時，會移除重新導向 URI 中的查詢字串和片段。
在設定用來登入個人 Microsoft 帳戶和公司或學校帳戶的應用程式註冊中，目前不支援萬用字元 URI。 不過，允許設定為只會登入組織 Microsoft Entra 租用戶中的公司或學校帳戶的應用程式使用萬用字元 URI。
若要在登入公司或學校帳戶的應用程式註冊中新增具有萬用字元的重新導向 URI，請在 Azure 入口網站中使用應用程式註冊中的應用程式資訊清單編輯器。 雖然您可以使用資訊清單編輯器設定具有萬用字元的重新導向 URI，但強烈建議您遵循 RFC 6749 3.1.2 節的指示。 並且只使用絕對 URI。
如果您案例需要的重新導向 URI 數目超過允許的上限，請考慮下列狀態參數方法，而不是新增萬用字元重新導向 URI。
使用狀態參數
如果您有數個子網域，而且您的案例需要您在成功驗證時將使用者重新導向至其一開始的相同頁面，則使用狀態參數可能會很實用。
在此方法中：
- 您可以建立每個應用程式的「共用」重新導向 URI，以處理從授權端點接收的安全性權杖。
- 您的應用程式可以在狀態參數中，傳送應用程式專屬的參數 (例如，使用者原本所在的子網域 URL，或商標資訊之類的任何項目)。 使用狀態參數時，請透過 CSRF 保護進行防護，如 RFC 6749 的第 10.12 節 所指定。
- 應用程式特定參數包含應用程式為使用者呈現正確體驗所需的所有資訊，也就是建構適當的應用程式狀態。 Microsoft Entra 授權端點會從狀態參數中移除 HTML，因此請確定您未在此參數中傳遞 HTML 內容。
- 當 Microsoft Entra ID 傳送回應至「共用」重新導向 URI 時，它會將狀態參數傳回應用程式。
- 然後，應用程式可以使用狀態參數中的值來決定接著要傳送使用者到哪個 URL。 請確定您已針對 CSRF 保護進行驗證。
警告
此方法可讓遭入侵的用戶端修改狀態參數中傳送的其他參數，藉此將使用者重新導向至不同的 URL，也就是 RFC 6819 中所述的開放重新導向程式威脅。 因此，用戶端必須藉由將狀態加密來保護這些參數，或以其他方式進行驗證，例如在重新導向 URI 中驗證權杖的網域名稱。
下一步
深入了解應用程式註冊的應用程式資訊清單。