Better Auth0 OIDC support

[marius-mather]

Adding a specific provider/subclass for Auth0 OIDC (I also added an Auth0 OIDC class to python-social-auth). In our Auth0 implementation we have so far relied on the generic OIDC provider, but it's helpful to have a specific provider class for it, particularly to get refresh tokens working correctly.

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[nuwang]

@marius-mather I think it's be great to make the default GalaxyOpenIDConnect more generic if we can, rather than introduce more providers. Assuming Auth0 is largely compliant with generic oidc, what are we missing in the base provider, and can we add it so other providers can also make use of it?

[marius-mather]

@nuwang one of the main things I did when adding an Auth0 OIDC backend to python-social-auth was allow it to be configured via the Auth0 domain - which is a lot more convenient, but not 100% necessary. There's also some mapping of the Auth0 profile fields so we can get full profile details.

In terms of the galaxy implementation and making it more generic, I guess the main thing that would be needed would be the option to set social-auth's EXTRA_DATA fields, which could be clunky in the XML as it can involve nested lists.

I think having an Auth0 specific provider class is cleaner, and relies less on the somewhat clunky XML parsing currently used for backend config.