fix: use userinfo() with okta and don't try decoding a hash as json

[Lewiscowles1986]

Description

This plainly doesn't work with Okta, and it is not so hard to get it to work with Okta... There is no custom security class, no hacks to rely on identity token, just using the metadata url, to do what it should.

Fixes #2291

ADDITIONAL INFORMATION

• Has associated issue:
• Is CRUD MVC related.
• Is Auth, RBAC security related.
• Changes the security db schema.
• Introduces new feature
• Removes existing feature

I Would love it if someone can cut a release once this merges, so that I can build a superset image based upon this.

[jtv8]

Am not a contributor to this repo but by coincidence I've also been trying to trace this issue today.

I believe this PR would fix a non-obvious "gotcha" when configuring a provider with the name "okta" - it requires api_base_url to be supplied as well as server_metadata_url in remote_app. This should not be necessary as all the relevant endpoints are supplied by querying the server metadata.

In fact, it already works just fine if you name your provider something other than "okta"!

To continue down this train of thought - I think flask_appbuilder/security/manager.py could take better advantage of the fact that all these providers support OpenID Connect, which exists to standardize these interactions. It could benefit from some heavy refactoring to extract the common logic for retrieving data from the userinfo endpoint, which is done inconsistently throughout.

The mappings of the retrieved data to flask_appbuilder's user info values needn't be hardcoded either - some organizations might wish to customize them. It might be better to provide them as overridable defaults for each provider. Allowing the values to be extracted from the ID token claims (if present) could also prevent the need for a round trip to the userinfo endpoint altogether.

[Lewiscowles1986]

@jtv8 while this feels related, the problem I am solving actually relates to the Apache Superset usage of this library, where additional conventions have been setup around this.

We've actually gone old-school and manually pulled and patched the manager.py in that superset to this, and it works. Technically changing from Okta to auth0 can make this work, but not when using the conventions of Apache Superset where client and server are lock-stepped.

If you look at the auth0 just below okta definition, we are essentially borrowing from another of Okta's services (Auth0) conventions, to get this to work.

Server metadata url is not required by the way, you could also define the user info endpoint url, but I like that I can set the base uri and the metadata url and be more or less done.