To implement a centralized redirect service with Ory that then redirects to a different URL on login, you can use the

return_to

query parameter in combination with allowed return URLs. Here's the best approach: 1. Configure allowed return URLs: First, whitelist the domain of your centralized redirect service in your Ory project configuration. This prevents open redirect attacks. You can do this in the Ory Console or using the CLI [as described in the documentation](https://www.ory.sh/docs/concepts/redirects#allow-list). 2. Use the

return_to

parameter: When initiating the login flow, append the

return_to

query parameter to the login URL. The value should be the URL of your centralized redirect service, including an encoded parameter for the final destination. For example:

/.ory/self-service/login/browser?return_to=<https://redirect.example.com/?final_destination=https%3A%2F%2Ffinal.example.com>

3. Handle the redirect: Your centralized redirect service should receive the redirect from Ory after a successful login. It can then extract the final destination from its own parameters and perform the second redirect. 4. Persistence across flows: Be aware that the

return_to

parameter doesn't automatically persist across different flows. If a user switches from login to registration, for example, you'll need to handle this in your application logic [as explained in the documentation](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-advanced-integration#advanced-redirects). 5. Consider using Ory Proxy: If you're developing locally, you might find it helpful to use Ory Proxy. It allows you to use

/.ory

prefixed URLs and handles some complexities around cookies and domains [as described in the Ory Proxy documentation](https://www.ory.sh/docs/guides/cli/proxy-and-tunnel#ory-proxy). Remember to always validate and sanitize URLs in your centralized redirect service to prevent potential security issues. This approach allows you to maintain a centralized redirect while working within Ory's security model for handling redirects.

You're correct, and I apologize for any confusion in my previous answer. You're right that the allow list doesn't support dynamic query parameters directly. Let me clarify the situation based on the Ory documentation: The allow list in Ory is designed to prevent open redirect attacks by allowing only specific domains or paths. As stated in the [Ory documentation on redirects](https://www.ory.sh/docs/concepts/redirects#allow-list): "The

allow list

prevents Open Redirect Attacks by just allowing certain domains, or paths on a domain." This means that you can't directly use dynamic query parameters in the allow list. The allow list is meant for static URLs or patterns. For your use case of a centralized redirect service, you have a few options: 1. Whitelist the base URL of your centralized redirect service: You can add the base URL of your redirect service to the allow list. For example:

selfservice:      allowed_return_urls:        - <https://redirect.example.com/>

This would allow redirects to your service, but you'd need to handle the final destination within your service. 2. Use a fixed path structure: If possible, structure your centralized redirect service to use fixed paths that you can whitelist. For example:

selfservice:      allowed_return_urls:        - <https://redirect.example.com/login-redirect/>        - <https://redirect.example.com/register-redirect/>

3. Handle redirects in your application logic: Instead of relying on Ory's redirect mechanism, you could handle the final redirect in your application after the Ory flow completes. This would require more custom logic but gives you more flexibility. 4. Consider using Ory's post-flow redirect configuration: Ory allows you to configure redirects after specific flows. You could set this to your centralized redirect service and handle the final destination there. [This is explained in the Ory documentation on redirection](https://www.ory.sh/docs/kratos/concepts/browser-redirect-flow-completion#redirection). Remember, these approaches prioritize security by preventing open redirect vulnerabilities. While they may require some additional setup or logic in your application, they help ensure that redirects are handled safely.