繞過 Azure B2C 重定向 uri 限制

Question

背景

使用 Azure B2C 配置身份驗證時，您在 Azure 中注冊您的應用程序並指定允許 Azure 重定向回的返回 Uri。 這些重定向 Uri 的最大限制為 256 個 uri 。 我為其實現此功能的客戶有多個子域和頂級域，這些子域和頂級域指向具有不同文化的同一站點（使用 Optimizely CMS）。 這意味着如果所有這些都在應用程序中注冊，他們將突破 256 個 Uri 的限制。 此外，在應用程序注冊中配置每個 Uri 將是一項繁瑣的工作。 因此，我試圖在不破壞最佳實踐的情況下找出解決此問題的最佳方法。

期待

我希望找到一種解決方案，讓我只需要在 Azure 應用程序注冊中注冊一個或一個完整的重定向 Uri，但仍然能夠使用多個不同的子域和頂級域來啟動身份驗證流程。

方法

狀態參數使用狀態參數，您可以在整個身份驗證流程中傳遞自定義數據。 通過這種方式，您可以傳遞自己的重定向 Uri。 但是，這似乎只適用於路徑和子域，而不適用於頂級域。 如果我傳遞的頂級域與我正在啟動身份驗證的頂級域不同，我最終會陷入重定向循環。 我的猜測是，這是由於 cookie 無法設置，因為它是跨域的。

通配符 Uri's通過使用通配符定義 Uri's，可以最大限度地減少注冊域的數量。 但由於安全隱患，不推薦使用這種方法。

多個應用注冊一種方法是配置 OpenIdConnect 解決方案來處理多個應用注冊。 因此，一組 Uri 連接到一個應用程序注冊，另一組連接到另一個應用程序。 並且根據請求 url，使用正確的應用程序注冊來發起身份驗證請求。 這對我來說是一個很好的解決方案，但它並沒有減少添加所有重定向 Uri 和維護它們所需的工作量。

在自定義解決方案中包裝身份驗證流程在這種方法中，只有一個特定的頂級域（域 A）將用於啟動對 Azure B2C 的身份驗證。 想要從域 B 登錄的用戶將單擊登錄按鈕，該按鈕會將用戶重定向到域 A，在域 A 中啟動對 Azure B2C 的身份驗證。 當用戶通過身份驗證時，用戶將被重定向回域 A，在域 A 中創建令牌（或類似的），然后發送回域 B。當令牌到達域 B 時，它被保存在會話中，然后用戶被認為已通過身份驗證。 我不喜歡這種方法。 如果使用這種方法，感覺 Azure B2C 的全部目的都會丟失，而且這會增加更多的復雜性和攻擊向量。

問題

您會推薦這些方法嗎？ 我錯過了其他可能有效的方法嗎？

Answer 1

作為前 Episerver/Optimizely 開發人員，我不得不說，如果您超過 256 個域/子域，我會重新考慮您的架構方法。 您是否為每個語言版本使用不同的子域？

無論如何，如果您堅持您的方法，我建議將每個頂級域注冊為單個重定向 Uri，然后處理狀態中的子域/路徑。 這可能意味着身份驗證是在www.domain.com下處理的，然后使用狀態將您重定向回en.domain.com或de.domain.com 。 這可能需要實現一個自定義控制器來正確處理身份驗證流程、狀態和設置 cookie 域。