Deprecate OIDC Authorization code grant support and usage

[soxofaan]

The initial OIDC implementation in the openEO python client was focused on the Authorization code grant (the flow that works with redirect urls and such).
Getting this working in a python client context is far from trivial in practice because of the networking aspects of the redirect url.

Now that the Device Authorization Grant (aka device flow) is getting more popular and more widely supported, nobody is probably going to use the Authorization code grant.

Possible action points

• current documentation is currently is quite focused on Authorization Code Grant (in terms of priority and documentation volume). The device auth grant should get more focus instead
• remove implementation parts related to Auth Code Grant, which should make the OIDC implementation easier to maintain

[m-mohr]

I think as long as e.g. also the client credentials flow is supported as a more widely supported flow is also available here (is it? I think it would make sense...), the auth code flow is probably not really required. I would think just device code may be still not widely implemented enough, but if there's a more common alternative, the deprecation/removal is fine

[soxofaan]

client credentials flow is supported as a more widely supported flow is also available here (is it? I think it would make sense...)

Client credentials flow It is supported, but the problem with it is that it only allows to identify the (OIDC) client, not the user using that client, so you can not really leverage that to get to user level properties you usually want (access rights, billing plans, ...).

FYI: at the moment I am mainly thinking about changing the focus/emphasis in the documentation, not really changing implementation details

[m-mohr]

Client credentials flow It is supported, but the problem with it is that it only allows to identify the (OIDC) client, not the user using that client, so you can not really leverage that to get to user level properties you usually want (access rights, billing plans, ...).

Ah, that's correct... the main point was to not only rely on device code anyway. :-)