Ory does not support passing a fully custom and dynamic

redirect_uri

per individual social login request for providers like Google, Facebook, or Apple. Instead, Ory uses a configured base redirect URI for all social sign-in flows. This base redirect URI can be set to your custom domain, but it applies globally to all social sign-in providers and all flows—it's not possible to override it dynamically per request or per provider. To set a custom domain as the redirect URI, you must update the

base_redirect_uri

in your Ory project configuration. After changing this, you also need to update the redirect URI in your social provider's configuration to match. This setting is global and cannot be changed on a per-provider or per-request basis. Changing the

base_redirect_uri

will affect all social sign-in connections and may break existing integrations if not updated everywhere accordingly [Set custom domain as redirect URL](https://www.ory.sh/docs/identities/sign-in/social-sign-in/redirect-url). For multi-domain (multi-CNAME) setups, Ory will redirect users back to the domain where the flow started, as long as the initial flow was initiated from a custom domain. However, the actual

redirect_uri

sent to the social provider must still match the one registered with the provider and set in Ory's configuration. Using the

?return_to=

query parameter can help redirect users to different domains after authentication, but it does not change the

redirect_uri

used in the OAuth/OIDC flow itself [Ability to configure UI redirects by domain (in multi-CNAME setups)](https://github.com/ory/network/issues/218). In summary: - The

redirect_uri

for social login is set globally via the

base_redirect_uri

and cannot be dynamically changed per request. - You can use the

?return_to=

parameter to control post-login redirection within your app, but not the OAuth/OIDC

redirect_uri

. - For social providers, the

redirect_uri

must always match the one registered in their developer console and in Ory's configuration. If you need per-request dynamic

redirect_uri

support, this is not currently possible with Ory's social sign-in implementation.

To use the

return_to

query parameter with Google social login in Ory, you need to initialize the login flow with the

return_to

parameter set to your desired redirect URL. This ensures that after a successful login, the user is redirected to the specified URL. Below is a TypeScript example that demonstrates how to do this using the Ory SDK:

typescript import { FrontendApi, Configuration } from "@ory/client"  // Initialize the Ory SDK const ory = new FrontendApi(   new Configuration({     basePath: "https://<your-project-slug>.<http://projects.oryapis.com|projects.oryapis.com>",   }) )  // Example function to start a Google login flow with a custom return_to URL async function startGoogleLogin(returnToUrl: string) {   // Initialize the login flow with the return_to parameter   const { data: flow } = await ory.createBrowserLoginFlow({     returnTo: returnToUrl,   })    // Find the Google provider node in the flow UI nodes   const googleNode = flow.ui.nodes.find(     (node) =>       node.attributes.name === "provider" &&       node.attributes.value === "google"   )    if (!googleNode) {     throw new Error("Google provider not configured")   }    // Redirect the user to the Google login action   window.location.href = flow.ui.action + `&provider=google` }  // Usage example startGoogleLogin("<https://your-app.com/after-login>")

How it works: 1. The login flow is initialized with the

return_to

parameter set to your desired URL. 2. The user is redirected to the Google login by submitting the flow with the provider set to "google". 3. After successful authentication, Ory will redirect the user to the URL specified in

return_to

, provided it is allow-listed in your Ory configuration. Note: - The

return_to

URL must be allow-listed in your Ory project's configuration, otherwise the request will fail [Sign in](https://www.ory.sh/docs/identities/get-started/sign-in). - The same approach applies to other social providers like Facebook and Apple. For more details on advanced redirects and how the

return_to

parameter works, see the [Advanced integration documentation](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-advanced-integration#advanced-redirects). If you need to handle the flow in a custom UI, you can extract the

return_to

from the flow and pass it to subsequent flows as needed [Advanced integration](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-advanced-integration#advanced-redirects).

No wildcard is needed (and there’s no wildcard syntax like site.com/*). To use dynamic paths with return_to, add the base URL of your domain to the allow list. If the allow-listed entry is the domain root (for example, https://site.com/), any return_to pointing to a path under that domain will be accepted. [[Kratos redirection](https://www.ory.sh/docs/kratos/concepts/browser-redirect-flow-completion#redirection); [Browser redirects](https://www.ory.sh/docs/concepts/redirects)] Notes: - You must initialize the flow with the return_to query parameter. - If you need to restrict to a specific path, allow-list that exact path; otherwise, use the domain root to allow any path under it. [[Kratos redirection](https://www.ory.sh/docs/kratos/concepts/browser-redirect-flow-completion#redirection); [Browser redirects](https://www.ory.sh/docs/concepts/redirects#redirect-flows)]

Add it to the identity config’s allow list under selfservice.allowed_return_urls. Use a fully qualified URL (with scheme). Example:

yaml selfservice:   allowed_return_urls:     - <https://site.com/>     - <https://sub.site.com/only/path>

- Using the domain root (https://site.com/) allows any path on that domain; specifying a path restricts to that exact subdomain/path. [[Kratos redirection](https://www.ory.sh/docs/kratos/concepts/browser-redirect-flow-completion#redirection); [Browser redirects](https://www.ory.sh/docs/concepts/redirects)] - The URL must be valid (include http/https), and Ory-owned domains can’t be used. [[Troubleshooting](https://www.ory.sh/docs/concepts/redirects#troubleshooting)]

I’m sorry, but the knowledge sources don’t show a specific screen in the Ory Console to manage the allow list for return_to. They only document the config key you need to set: selfservice.allowed_return_urls. [[Kratos redirection](https://www.ory.sh/docs/kratos/concepts/browser-redirect-flow-completion#redirection)] If you can’t find it in the Console, add the domains via configuration (for example, by updating identity config) so that selfservice.allowed_return_urls includes your allowed origins. [[Kratos redirection](https://www.ory.sh/docs/kratos/concepts/browser-redirect-flow-completion#redirection)]

You can add allowed_return_urls with the Ory CLI by patching the Identities config:

bash # Add (creates the key if missing) ory patch identity-config --project <project-id> --workspace <workspace-id> \   --add '/selfservice/allowed_return_urls=["<https://site.com/>","<https://sub.site.com/only/path>"]'

If the key already exists and you want to overwrite it:

bash ory patch identity-config --project <project-id> --workspace <workspace-id> \   --replace '/selfservice/allowed_return_urls=["<https://site.com/>","<https://sub.site.com/only/path>"]'

- Use fully qualified URLs (with scheme). Adding the domain root (for example, https://site.com/) allows any path on that domain; specifying a path restricts it. [[Kratos redirection](https://www.ory.sh/docs/kratos/concepts/browser-redirect-flow-completion#redirection); [Browser redirects](https://www.ory.sh/docs/concepts/redirects)] - Patch commands and flags are documented here. [[Identities CLI](https://www.ory.sh/docs/guides/cli/identity-cli)]

Here’s what happened and how it was fixed: - The login flow failed to initialize because the return_to URL’s domain wasn’t on the allow list (selfservice.allowed_return_urls). Ory blocks flows with unlisted return_to targets to prevent open redirects, so initialization errored out. [[Kratos redirection](https://www.ory.sh/docs/kratos/concepts/browser-redirect-flow-completion#redirection); [Browser redirects](https://www.ory.sh/docs/concepts/redirects)] - In production, we only had a path-scoped entry (https://ourdomain.com/api/.ory). That restricts return_to to that exact subdomain/path. We replaced it with the domain root (https://ourdomain.com), which allows any path on that domain (acts like a wildcard for paths). [[Browser redirects](https://www.ory.sh/docs/concepts/redirects); [Kratos redirection](https://www.ory.sh/docs/kratos/concepts/browser-redirect-flow-completion#redirection)] Fix (no redeploy needed) using the CLI:

bash # Replace the allow list to permit any path on the main domain ory patch identity-config --project <project-id> --workspace <workspace-id> \   --replace '/selfservice/allowed_return_urls=["<https://ourdomain.com/>"]'

This uses the ory patch identity-config command to update configuration live. [[Magic links](https://www.ory.sh/docs/troubleshooting/magic-link-verification-url); [Social redirect URL](https://www.ory.sh/docs/identities/sign-in/social-sign-in/redirect-url)] Result: the return_to validation now succeeds and the login flow initializes and completes as expected. [[Kratos redirection](https://www.ory.sh/docs/kratos/concepts/browser-redirect-flow-completion#redirection)]