Open soxofaan opened 3 years ago
m-mohr
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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. :-)
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