Enabling authentication via GitHub with your own application in Dev portal doesn't work

This issue has been reproduced by rhn-support-dmayorov, who provided information below.

Expected behaviour:
When you put your Client ID and Client Secret of your own GitHub application, the authentication should be performed using this custom application. Also, I would expect in SaaS to see the "state" of the integration – whether it's "3scale branded" or "custom branded", as shown on this screenshot from the Developer Portal authentication section > 5.2 Enabling and disabling authentication via GitHub.

Current behaviour:
Even though the custom Client ID and Client Secret are configured, the authentication is still going through the default "3scale branded" GitHub application. You can see if if you examine the "Test authentication flow" URL – it includes the 3scale's Client ID for GitHub app.

Further troubleshooting:

• If you GET the Authentication Providers Developer Portal List with the 3scale API, you can see that its state is "3scale branded".
• It is not possible to change the state with Authentication Provider Developer Portal Update because the state field is not exposed.
• You can specify the desired state via Authentication Provider Developer Portal Create endpoint (branding_state_event=custom_brand). However we can't use Create because only one provider of the given type "GitHub" is allowed and it is not possible to delete the auth provider with the 3scale API or via UI.

A potential workaround could be to change this field by API, but unfortunately this field is not accessible through the "Authentication Provider Developer Portal Update" endpoint.
As mentioned above, you can actually specify the desired state via "Authentication Provider Developer Portal Create" endpoint (branding_state_event=custom_brand), but this is not exposed on "Update". And we can't use "Create" because only one provider of the given type "GitHub" is allowed. And there is also no way to delete and create the auth provider, AFAIK.

Dev notes

We decide to just allow workaround by allowing update for the custom_brand state in the API