AspNet.Security.OAuth.Providers: Mixcloud Does Not Appear to Support the `state` Parameter

Hey @Mike-E-angelo , Mixcloud’s customer support has forwarded me your emails and I’ll be looking into this as soon as I can

I’ll let you know here once I have more info/if we’ve done the changes you asked 😃

PS: I work for Mixcloud

Edit: This isn’t forgotten, I had some time-off/got pulled elsewhere : )

Naturally, after my Grumpy McGrumpyface rant, I received a reply from MixCloud that this should be fixed now that we should try again.

😁😅😭

I will add this to my things to do. I suddenly got swamped with a ton of tasks so it should be later this week, if not the weekend. I will update here either way as soon as I can. 👍

Whew finally putting this thing out of its misery. I will never have anything to do with Mixcloud again and regret ever opening this issue 😭

Regardless of whether or not it’s in the spec, with no client to test with, it’s hard to validate that any fix fixes your bug

Thank you very much for checking in here @ben-xo and for your time investigating this issue. At the risk of piling on here, however, I do share the concern and frustration with others here about how long it has taken to address this issue as well as the continued misunderstanding on what exactly the issue here is.

1. The issue in no way involves C# outside of the fact that a C# client is involved to integrate with your provided API. You can think of this client as a wrapper around the CURL/web calls that you yourself provide in your own documentation here.
2. As this is indeed defined – and as noted, required – by the OAuth2 specification, you are free to use any client you originally used to test your Oauth2 implementation and API. This is overkill, however, as a simple call via Postman (as has already been suggested) is all you need to test/verify on your end.
3. There appears to be confusion about this thread’s intent. The intent of this thread was to track a broken API on Mixcloud’s side. And, unfortunately, it still is tracking over a year after the fact. 😞 It was opened here as it appears that we were the first to notice this issue and wanted to have a way to bring it to your attention, as well as offer a place for any collaboration/communication. That is, we invited you here to discuss and collaborate to get it fixed on your end. Getting it fixed on your end means that it works on all the clients/integrations that you already own and have published. This would mean the Ruby client mentioned at the bottom of this page, and basic web requests as provided by your documentation. Once all those are working, then we can verify it here as well (again since what we do here is a basic CURL wrapper it should “just work” along with all the other clients).

To summarize, there is nothing special about C# or this repository with regards to this issue, except that it expects a fully-compliant Oauth2 as developed by your team. As such, this issue as identified is an incomplete implementation of the Oauth2 specification on Mixcloud’s side, and the GitHub issue here is meant to track it in a C# client implementation which in turn expects a fully operational/compliant Oauth2 implementation.

At the risk of a bad pun, I hope this further clarifies the “state” of this issue here. 😁

Woo, to be honest, this is getting quite ridiculous, don’t you guys have test clients you use internally to test your own server implementation? (well, I guess not, otherwise we wouldn’t have this thread opened for more than a year 🤣)

Anyway, it’s easy to test using a program like Postman (authorization tab -> OAuth 2.0: fill in the form and click on “Get New Access Token”) or manually by constructing the request URL yourself and using your preferred browser:

https://www.mixcloud.com/oauth/authorize?client_id=the_client_id_of_a_registered_client&redirect_uri=the_redirect_uri_of_a_registered_client&state=xyz

If you’re redirected to the_redirect_uri_of_a_registered_client?code=abc&state=xyz (if the authorization is approved) or the_redirect_uri_of_a_registered_client?error=access_denied&state=xyz (it you refused the authorization demand), it works. Otherwise, it doesn’t.

Alright, I have heard back from MixCloud customer support. This issue has been identified as a bug on their end and is slated to be worked on fixing it Soon™.

https://youtu.be/Bro-WwwroEA

No timetable/estimate, however.

Hi @limaAniceto - any update on this from Mixcloud?

Closing for now. If Mixcloud fixes/improves their implementation in the future, we’ll revisit that.

I added a Mixcloud integration to the new OpenIddict client (https://github.com/openiddict/openiddict-core/pull/1594) and I can confirm the state issue hasn’t been fixed and that a workaround is still needed.

(oh, and they return JSON responses as text/javascript responses 🤣)

I’m personally speechless.

Proper state support is absolutely essential to the security of an OAuth 2.0 client as it prevents session fixation/forged requests attacks (and, when implemented correctly, helps reduce the ability to steal authorization codes via referrer leakages). For the aspnet-contrib provider, we used a workaround to have a state-like mechanism but I really doubt most Mixcloud clients in the wild went that far. The number of applications vulnerable to the classes of attacks I mentioned should be astonishing…

You can use the client in our samples directory.

The time to fix is indeterminate.

Haha, it’s indeed getting really ridiculous, given how easy this should be to fix. For reference, in OpenIddict, it’s implemented in literally 3 lines of code 🤣

// If the user agent is expected to be redirected to the client application, attach the request
// state to the authorization response to help the client mitigate CSRF/session fixation attacks.
//
// Note: don't override the state if one was already attached to the response instance.
if (!string.IsNullOrEmpty(context.RedirectUri) && string.IsNullOrEmpty(context.Response.State))
{
    context.Response.State = context.Request?.State;
}

Hey @limaAniceto. Do you have (good) news for us? 😃

Cool - thanks for the update. I’ll leave this issue open until we hear back from them.