Ensure the OpenIddict client implements all the hooks necessary to deal with non-standard providers

[kevinchalet]

Confirm you've already contributed to this project or that you sponsor it

• [X] I confirm I'm a sponsor or a contributor

Describe the solution you'd like

https://github.com/aspnet-contrib/AspNet.Security.OAuth.Providers currently offers ~80 providers: many of them don't include any specific hack to deal with a non-standard aspect of the OAuth 2.0 specification but some do. We should make a global pass to determine whether the OpenIddict base client will offer all the hooks necessary to work with the worst offenders.

Additional context

No response

[kevinchalet]

• Alipay is by far the worst of the worst: it requires mapping authorization response parameters (e.g auth_code -> code, it uses custom token request parameters, requires using GET and sending these parameters in the query string, forces us to use a custom RSA-based request hashing method for both token and userinfo requests and returns 200 for errored responses... 🤣

• ~Deezer (a French service! 😠) also requires doing some heavy parameters mapping and sending GET token requests~.

• eBay doesn't allow sending a URI as the redirect_uri and uses a non-standard "RuName" concept.

• EVEOnline requires introspecting the access token - a JWT - to extract the user information.

• ExactOnline (it's not the only one) returns its userinfo responses in nested d nodes. Foursquare does something similar by wrapping the actual result in a response node.

• ~LinkedIn doesn't support Accept-based content-type negotiation and uses a custom x-li-format header~. A few other providers do that too. They also use custom error codes to indicate that the user denied the authorization demand.

• ~Mixcloud used to require a hack to work around the lack of state support but recent reports indicate that state is now supported~.

• Myob returns the user information directly as part of token responses.

• Nextcloud uses dynamic userinfo endpoints whose address must contain the user ID resolved from a token response parameter.

• Odnoklassniki uses a custom "MD5 hash-as-a-signature" and requires sending additional parameters for the userinfo request.

• QQ requires sending a fmt to opt in JSON responses (otherwise you get formurl-encoded responses or JSONP). It also requires sending a few other parameters and uses 200 error responses.

• Shopify is multitenant and it's been implemented dynamically in the aspnet-contrib provider to allow choosing the "shop name" per authentication challenge.

• ~StackExchange returns formurl-encoded token responses (!) and seems to require using a HttpClientHandler with AutomaticDecompression = DecompressionMethods.GZip~.

• ~Trakt requires sending the API version as a special trakt-api-version header~.

• Trovo requires sending JSON token requests and forces using OAuth as the authentication scheme for userinfo requests.

• Untappd, like a few other providers, uses GET token requests and wraps token responses in a response node.

• Visual Studio Online uses a completely non-standard grant that uses static client assertions and authorization codes-as-assertions.

• Weibo uses dynamic userinfo endpoints whose address must contain the user ID resolved from a token response parameter.

• Weixin also requires doing some heavy parameters mapping and sending GET token requests.

• WorkWeixin uses a non-standard authorization code flow that doesn't send the code flow as part of token requests...

• Yammer doesn't return a standard token response so heavy mapping will be required.

• Zalo, like a few others, requires using app_id/app_secret instead of the standard client credentials parameters.