Support new JWT token based auth (openEO API 1.3.0)

[niebl]

#850

Includes:

• checking conformance in connection.authenticate_basic() and connection.authenticate_oidc() and formatting the bearer tokens accordingly
• a /conformance endpoint in DummyBackend and a has_conformance({url}) method in capabilities. So JWT bearer token conformance can be checked.

[niebl]

still WIP, as testing with JWT conformant backends is not yet implemented (manual tests have shown that there is still something going wrong though)

[soxofaan]

great, thanks for this effort

some notes:

[soxofaan]

Instead of duplicating tests for JWT conformace mode (like this single test_authenticate_oidc_auth_code_pkce_flow), I think we should look instead into parameterizing all existing tests here.

e.g. there are 41 occurrences of assert.*bearer.*oidc/ in this file, so there is a lot of test coverage that should be ported to JWT conformance mode (as it is meant to become the default/recommended approach)

[niebl]

hi @soxofaan,
that's a lot of test coverage.
1d5c20f now uses both 1.0.0 and 1.3.0 versions as parameters.

There are still five failing tests under version 1.3.0, namely the tests from test_authenticate_oidc_auto_renew_expired_access_token_invalid_refresh_token to test_authenticate_oidc_auto_renew_expired_access_token_initial_device_code

All of these have in common that they use the get_me_handler to extract access token and oidc_provider from the bearer token. This could be changed to extract the oicd provider from the iss issuer-attribute in the jwt, but afaik that is not yet included in the example bearer tokens and would need to be implemented first.

Should we change those parts of the code accordingly so the get_me_handler can also pick the oidc_provider from he token?

[soxofaan]

some more notes

[niebl]

It turned out that the changes made to DummyBackend never see any use in testing. So I am uncertain whether these and the changes to test_testing.py are truly needed after all.

Left them in for now but can be removed if not needed.

[soxofaan]

hmm, it seems this PR got in a bad state, making the signal/noise ratio bad for review. I see various changes in places that are unrelated to the feature to implement here (conversions.py, results.py, _version.py, metadata.py, test_s3sts.py, ...)

did you by any chance cherry-picked commits from master, instead of merging master?

[m-mohr]

@soxofaan I did clean up a potentially failed merge, this should improve the situation.

Somehat related: We also have changes come in from the linter for some of those files each time we run the linter. It might be that master is not clean with regards to linting?! => #869