What is the syntax for wildcards in the callback url?

Any progress / ETA in this?

We are using multiple subdomains for different environments and tenants. Wildcard support would be highly appreciated

I'm using cognito for openid connect auth.
If user opens a page and needs a login, I'd like him to be redirected to the same page after login. so my callback url is

http://xxxxxxx/auth?target=somepage.html

the base url is same but with different target parameter.
is there any way to do it?

You can use the "state" parameter to pass the information about the page you want to redirect the user to. Cognito will pass the state value to your callback endpoint.

Hi,

We have created a feature request on this and have put that on our road map. However, we don't have any ETA yet on this but please be assured that we are working on the same.
I kindly request you to keep an eye on AWS what’s new[1] page and AWS blogs[2] to get information regarding the updates on the above as well as for recent updates on other AWS services.
[1] https://aws.amazon.com/new/
[2] https://aws.amazon.com/blogs/aws/

Callback URL wildcards still aren't there. Could you shed some light on the state of affairs?

We do not support wildcard callback URLs due to security reasons.

Regarding adding the callback URL option in CloudFormation AWS::Cognito::UserPoolClient, we have heard this request from customers and we will try incorporating in our future releases.

I think we can use wildcard for subdomain without security risk if someone wanted to. Let's say example.com is the domain then callback URL would be something like: https://*.example.com/oauth2/idpresponse

@sarthak-AWS - agree this would be a competitive edge / unique feature for Cognito - branch deploys are super common now but no one can authenticate them without loading new urls every time.

I second that, and that's exactly what we do for our deployments, they all go uder a sub-domain and then I have to manually add the url each time. Would be amaxing to have a wildcard since the domain used is our own *.abcdecompany.com would be perfect to take the manual step out of the deployment process.

What I find most humorous about this is that this is where Amazon draws the line of "We have to adhere to the spec". They can't even adhere to the actual Oauth spec dealing with Nonces. Entire branches and fixes are applied to react projects (next.js / next-auth) to support the fact that they're ignoring that part of the OAuth process, but they'll be super opinionated about client redirection.