CORS Errors when using wildcards for allowed callback URLs
When using wildcards in allowed callback URLs in combination with a custom domain, I'm getting CORS errors when trying to retrieve a token from the oauth/token endpoint. Is this expected behavior?
Actually detecting the validity of the callback/redirect URL works fine. Just that afterwards when I receive the login code on the callback and try to exchange it for an access token at the /oauth/token endpoint that we receive a CORS error.
When I explicitly specify which URLs are allowed this works just fine.
12 Replies
Hi, thanks for reaching out! Just to confirm my understanding: you're encountering CORS errors specifically when trying to exchange the login code for an access token at the
/oauth/token endpoint, and this only happens when using wildcards in the allowed callback URLs. However, when you explicitly specify the URLs instead of using wildcards, everything works as expected — is that correct?That's exactly what's happening yes. We were thinking about trying out wildcards since this makes managing organizations a slight bit simpler, but it seems to give some issues regarding CORS.
Thanks for confirming that! I’ll check in with the team regarding the CORS behavior when using wildcards in allowed callback URLs and get back to you as soon as I have more information.
Hi, thanks for your patience! The team suggested looking into using handles as a solution, which might better support your use case and simplify managing multiple orgs. You can find more details here: https://docs.kinde.com/build/domains/subdomains-for-callbacks/
Let me know if this helps or if you have any further questions!
I will give this a try, but is it expected behavior then when working purely with wildcards that CORS errors can occur?
And can the handle of an organization be set via the Kinde Management API?
Also can we somehow add the organization's handle to our access token claims?
This works for login callbacks, but doesnt seem to work for logout callbacks, here we would also need the dynamic callback system in this case.
Hi,
Thanks for your detailed questions!
Regarding the first one on whether it's expected behaviour for CORS errors to occur when working purely with wildcards — I’ll check in with our team on that and get back to you shortly.
As for your second question — yes, you can set an organization’s handle via the Kinde Management API using the
🔗 Management API docs The
🔗 Add handles to your organizations Additional operations include: - Delete a handle → DELETE endpoint - View existing handles → GET endpoint Just a quick note — the handle must be unique within your Kinde business.
PATCH /api/v1/organization/{org_code} endpoint:🔗 Management API docs The
handle parameter should be included in the request body and must exactly match the subdomain you want to use:🔗 Add handles to your organizations Additional operations include: - Delete a handle → DELETE endpoint - View existing handles → GET endpoint Just a quick note — the handle must be unique within your Kinde business.
Kinde docs
Kinde Management API
The management API is for managing your Kinde account. Most things that can be done via the Kinde admin UI can be done with this API
Kinde docs
Org handles and dynamic callbacks for subdomains
Our developer tools provide everything you need to get started with Kinde.
Following up on your question about including the organization’s handle in the access token:
At the moment, there’s no built-in claim for the organization handle in the access token. I’ll check with our team to see if there’s a recommended workaround for this and get back to you.
In the meantime, you can retrieve an organization's handle by making a
GET request to the /api/v1/organization endpoint using the organization code as a query parameter. Here's an example of the response you'd receive:
To make this request, your access token must include the read:organizations scope.
As for the issue with logout callbacks not behaving the same way as login callbacks — I’ll raise this with our team and get back to you once we’ve looked into it.Thanks for the information, for now our organization provisioning system is simply adding callback url's for login and logout so nothing is really going wrong here.
Just wondering if it could be simplified and trying to understand why exactly behaviour is different in the below cases.
- Explicit callback urls for and work perfectly fine and everything is as expected.
- Wildcards being set as and are causing CORS errors on the /oauth2/token endpoint.
- Organization handle based callbacks set as and are not causing CORS errors but are not respecting the logout callback correctly, leaving us at the generic Kinde hosted screen.
In each of these cases domain.com would be our custom domain that's set-up with Kinde.
Regarding reproduction of this behavior, if any other application within the environment in Kinde does contain explicit callback urls for a specific subdomain, and this subdomain is used for authenticating against a application with only wildcards, everything works fine. The CORS errors would only occur when ALL applications ONLY contain wildcards.
Thanks so much for the clear breakdown — really appreciate the way you’ve outlined each case.
You're absolutely right in your observations, and your summary helps a lot in narrowing things down:
- Explicit callback URLs behave exactly as expected.
- Wildcard callbacks (
*.domain.com) can trigger CORS errors on /oauth2/token, but only when all apps use wildcards exclusively.
- Organization handle-based callbacks don’t run into CORS issues but currently don’t respect the logout redirect properly, falling back to the default Kinde logout screen.
We'll take this back to the team to dig a bit deeper, especially into the logout behaviour for org handle-based callbacks and the CORS issue when no explicit callbacks are present.
In the meantime, if you have any additional context or if there are specific use cases you're looking to support, feel free to share — happy to keep working through this with you.Thanks for the feedback, no additional context or specific use cases for now. Let me know if the team does require any additional information, happy to get to the bottom of this.
Hi, just a quick note to let you know we haven’t forgotten about your request. We're still looking into the logout behaviour and CORS issues with the team. I’ll keep you posted as soon as we have more to share.
Thanks again for your patience and collaboration!
Thank you very much, looking forward to hopefully being able to simplify organization provisioning 🙂
Any updates regarding this?
Hi, thanks for checking in! The team is still actively looking into this, and the investigation is ongoing on our end. I’ll make sure to share any updates as soon as we have more to report.
Really appreciate your patience — and thanks again for your continued collaboration!