oauth-config.json: rework related classes for multi-(cloud)-provider support and better config provisioning

[brainstorm]

As discussed on:

#620 (comment)

The oauth/jwt implementation in IGV is in great need for a refactor and security audit.

In a more practical/pragmatic side, the provisioning of oauth-config.json organization-specific parameters should be re-thought so that it accomodates different (cloud) sources without conflicts between them, seamlessly and concurrently.

Right now clients should deposit ~/igv/oauth-config.json manually instead of fetching it from, for example, a public S3 bucket or similar mechanism, as implemented by PROPERTIES_URL for Google.

[jrobinso]

I agree, but don't have cycles for a major rethink here. However, at a minimum I think it should support the default Google provider + 1 more user configured one. As it is now I don't think a user will be able to fetch a google protected file when Amazon is enabled. I think this can be done fairly easily while making a step towards the general case. I doubt many users are going to fetch files from more than 2 providers.

We have to have some sort of user input to initialize a custom provider. Perhaps we could let them enter a url to the json file and read it from there.

[brainstorm]

I hear you on cycles Jim, likewise :-S

On priorities I think that the best and also long-hanging fruit win would be to solve the PROPERTIES_URL provisioning issue: Users mangle oauth-config.json in any way imaginable and makes troubleshooting and provisioning, well, troublesome.

A fix for that (other than supporting multiple clouds) would be much higher on my UX prio list IMHO.

What about having users set the "Provisioning URL" in settings like they do for custom servers on Preferences->Advanced?

That would at least fix the multiple user "copy and paste malformed JSON" issues we had :-S

[jrobinso]

@brainstorm Yes that is doable. However oauth-config.json is there from a much older PR, people are using it. The provisioning URL could just default to "oauth-config.json".

[jrobinso]

Config provisioning by URL as suggested is implemented and pushed to branch oauth_refactor. Also support for mutiple providers, actually exactly 2, a default provider + an optional Amazon provider.

The local copy of oauth-config.json is still supported. If it is present it will override the provisioning URL if they both configure an Amazon provider. Currently we support only 1 Amazon provider.

Generalizing this to N providers of unknown vendors will be hard. The chief difficulty being deciding which provider to authenticate against given a uri. This could possibly be keyed by host name or a list of host names, or protocol, or some combination. Additionally, sharing the same redirect uri will be problematic, we will probably have to use separate uris for each provider.

I will probably merge this branch after more testing on Monday, and we will release shortly after.

[brainstorm]

Tested it and works great for us, updated the blogpost/documentation accordingly with a settings->advanced field screenshot. Thanks for this change Jim, simplifies provisioning significantly!