Twitter v2: The oauth state was missing or invalid. about aspnet.security.oauth.providers HOT 6 CLOSED

This came up during the initial development of the provider but then went away: dotnet/aspnetcore#39664 (comment)

50:50 on whether it's a latent bug with some weird edge cases, or some latest CEO-driven development broke something on their end.

from aspnet.security.oauth.providers.

This issue was also discussed here: dotnet/aspnetcore#42192

50:50 on whether it's a latent bug with some weird edge cases, or some latest CEO-driven development broke something on their end.

It's neither a bug nor one of those stupid Musky decisions: the Twitter devs just opted for a way too short limit for the state parameter, that cannot exceed 500 chars exactly. If your AuthenticationProperties is populated with too much data (e.g because a large ReturnUrl is stored), the resulting DP-protected state will exceed Twitter's limit and you'll get a generic error.

@Mike-E-angelo you could probably work around this issue by creating an ISecureDataFormat<AuthenticationProperties> that stores the actual data in a distributed cache and returns a reference ID with a fixed short length.

Alternatively, you can replace the aspnet-contrib Twitter by its OpenIddict equivalent, that doesn't suffer from this issue as the JWT state tokens it produces are stored in the DB. The OpenIddict client and its ~60 providers generally require a bit more configuration (as there's less magic involved) but is also much more flexible and comes with tons of additional security checks compared to the aspnet-contrib. More info here: https://kevinchalet.com/2022/12/16/getting-started-with-the-openiddict-web-providers/

from aspnet.security.oauth.providers.

Oh my goodness, thank you both @martincostello and @kevinchalet for your great support and guidance! It is greatly appreciated. It's also a far cry from Twitter which is really quite abysmal. You may or may not be aware of this, but developers are paying $5k/mo and not getting any dedicated support for the use of Twitter API. 🤯 In light of this and in comparison to Twitter support, I feel like I just got $5k worth of support from your responses alone. :D

It definitely makes me appreciative when I see replies here in GitHub from Microsoft repositories and on developercommunity the replies, and really after having to try deal with Twitter support, any acknowledgment of my existence. 😅 🙏🙏🙏

I will look into the IDistributedCache solution as this is something I have been meaning to do w/ my application, the whole scaling story and all. :D

I will close this ticket now that the limitation is understood. Thank you again for your efforts and time. 🙏

from aspnet.security.oauth.providers.

OK I got the ISecureDataFormat<AuthenticationProperties> implemented and everything works as expected, @kevinchalet. Thank you again for the guidance.

There is one hitch though and one I have been noodling on. The ISecureDataFormat<AuthenticationProperties is synchronous and IDistrubutedCache is asynchronous in nature. IDistributedCache has synchronous methods, of course, but if I understand correctly, that could possibly lead to thread starvation if enough calls are made concurrently.

I wanted to throw that your way and gauge my understanding of the situation. Is this something to worry about? Is there another consideration to make it asynchronous all the way? Thank you for any continued insight you can provide.

from aspnet.security.oauth.providers.

Two things I'd throw in the mix for your consideration:

1. How slow is your cache? If it's very fast, then any sync call isn't going to consume much resources.
2. How often do you actually expect people to be signing in and out of your application with Twitter? I would have thought relative to the rest of your application's purpose it would be small.

from aspnet.security.oauth.providers.

Much along the lines I have been thinking @martincostello. This is actually a limited scenario, so from the outset I would say it's OK to brave the sync path as there should not be much thread utilization during the process. However, if you know anything about the asynchronous underbelly of .NET there's a lot that can bite you. 😬

Additionally, even if the cache is typically fast, if it does hang for whatever reason (HTTP request to Redis, I am guessing) that is a thread that is being held up which is a Bad Thing™ as I understand it with the asynchronous model.

So, I guess I am wanting to be a little confident here that I can get away with this. Sounds like I can, but wanted to be sure of my reasoning. :)

from aspnet.security.oauth.providers.