#1

Hi,

I’m trying to authenticate users via OAuth 2.0 with PKCE on my singe-paged app.

Requests to oauth/token endpoint seem to fail due to CORS while it works if I request using curl which it doesn’t make sense since we need to request a token from browser in SPAs.

A bit tangentially it occasionally succeeds if I set the “Type of App” to Native App, but not always. (this doesn’t work right now).

Anywhere to setting extra allowed origins?

1 Like
#2

It seems to succeed or fail stochastically :thinking:

スクリーンショット 2021-12-21 23.51.01

1 Like
#3

Thanks for reaching out here. At this point, my understanding is that we don’t support CORS yet, but we’d like to in the future. I’m interested to hear more context about what you are looking to do and to learn about your use case and where you’d like to be able to set extra origins.

Thanks again!

1 Like
#4

Thank you for clarification and giving me opportunity to explain.

I’m gonna create a public client where a user can analyze his/her data while preserving the privacy, by making its source code of the SPA public so users can make sure how the app use their data. If I would get the access token on server side, users would compromise their ability to audit my usage.

#5

Thanks for your feedback and your suggestions. I talked to the team and we are considering adding CORS in 2022 as part of our roadmap planning.

Best,

Jessica

#6

Thanks as well, It would be really useful if CORS supported! Looking forward to hearing any updates.

1 Like
#7

Hey, I’m having the same issue, as @tnzk described. Can we get an approximate date for CORS support? I think it’s pretty necessarry, because a lot of applications today do not use backend a lot.

1 Like
#8

In terms of CORS support, this is something we’re in the early stages of having discussions around, so at this point, I am unable to give an approximate date.

1 Like
#9

Do you maybe have an update for us? Does Twitter still consider this? See: Twitter API v2 - Public Client - No: 'access-control-allow-origin' header present / CORS

#10

Hi,

This is still being considered, but I don’t have an update yet. But I’ll pass this feedback on to the team.

Thanks!

Jessica

1 Like
#11

@jessicagarson Thank you for your reply!

I’ve actually found a solution which works: my static (C#) Blazor WASM client now uses a YARP reverse proxy (with CORS functionality added) to make Twitter API requests.

  1. The static Blazor WASM client sends the Twitter API request to YARP
  2. YARP forwards the request to the Twitter API
  3. Then it receives the response back from the Twitter API
  4. It adds the necessary header to the response
  5. And then sends the response with the added header back to the Blazor WASM client.

See for more info this GitHub Q&A Discussion

1 Like
Twitter API v2 - Public Client - No: 'access-control-allow-origin' header present / CORS
#12

@jessicagarson (FYI, for you and the Twitter API Team) Why I like to let the client make calls directly to the Twitter API is about scaling. When you let the user’s browser do all of the ‘hard’ work (creating the request, serializing the response etc.) you save valuable server resources. The reverse proxy solution is also a step in the right direction to scale better. I can use a dedicated server (if needed) for YARP.

1 Like
#13

Oh wow, that solution is fantastic. Thanks for sharing. I’ll pass this feedback on to the team. This has been a long-standing feature request, and I think we’ll have a lot of opportunities in the future if we implement CORS.

2 Likes