support OIDC client credentials auth?

[soxofaan]

I'm not sure if this is even remotely feasible, but we recently had several users asking about this, so just putting this here for future reference:

Is it possible to use the openEO web editor with service accounts (which only support the OIDC "client credentials" grant)?

[m-mohr]

This is not really feasible for web apps as client credentials need a client secret, i.e. you'd need to enter client_id and client_secret for every login and then keep the browser open.

What's the usecase for a browser app? Usually a refresh token should cover a long enough time span...

[soxofaan]

The typical use case is users that use client credentials based machine-to-machine auth for non-interactive workflows, but still want to be able to follow up e.g. batch job progress through the web editor.

[m-mohr]

So effectively this would be implemented similar to a username (client ID)/password (client secret) login workflow?
This is effectively more an openeo-js-client issue as the underlying OIDC library is the limiting factor.

At some point we need to upgrade from the deprecated oidc-client-js to oidc-client-ts anyway, but it doesn't support client credentials either: https://github.com/authts/oidc-client-ts

So it would need a whole new library and I'm not sure which one would cover all our use cases. So this is a major effort.

[soxofaan]

I'm fine with the current assessment that the effort outweighs the added value at the moment.

To the user interested in a feature like this:
I'd like to point out that it is already possible to approximate this feature through Jupyter notebooks and the openEO python client:

• authenticate with client credentials, e.g. connection.authenticate_oidc_client_credentials() (make sure to properly handle your credentials, don't accidentally store them in git, if possible, leverage environment variable support)
• list your batch jobs with connection.list_jobs(), which will render a table overview that closely resembles the batch job overview from the web editor

[m-mohr]

Notes from the recent meeting with @jdries and @soxofaan:

• The current library (oidc-client-js) is unmaintained and supports only Implicit and AuthCode+PKCE
• A successor in the future could be oidc-client-ts, but it only supports AuthCode+PKCE
• Implementing client credentials would be a major effort as there's no known JS library that supports it, especially in the Browser (due to the usual client secret security issue) - in this case client id would be username, and client secret be password.
• Passing over the refresh token (and access token) from Python would be an option, but then the refresh token also has limited lifetime, so the benefit is potentially non-existant
• Logging on the server may be problematic as the tokens would usually be passed via query strings, making them visible in the logs. Having such information in logs is not ideal and could potentially be a security issue. Logging should be disabled then. Might be possible via fragment though (i.e. after the hash #)

The question really is how often this is really useful for users. Is there a big advantage over the lifetime of a refresh token? Users can simply login again after the refresh token expired.

[soxofaan]

Passing over the refresh token (and access token) from Python would be an option, ..
Logging on the server may be problematic as the tokens would usually be passed via query strings, making them visible in the logs. Having such information in logs is not ideal and could potentially be a security issue. Logging should be disabled then. Might be possible via fragment though (i.e. after the hash #)

An alternative approach to avoid passing tokens over GET requests, which indeed risks exposure through logs, is using POST requests. For example: python client POSTs tokens to some web editor end point, which sends back a short term (one-time) token. Python client then uses this token to build URL to forward user to web editor (with GET request).

[m-mohr]

The Web Editir is a static HTML page, so I don't think it can read from POST right now 🤔

[soxofaan]

ah ok nevermind then. I kind of vaguely remember that there was some dynamic component too (e.g. to clear/prime caches), but maybe that was for the hub

[m-mohr]

Nothing is impossible, it's just a matter of effort ;-)

[soxofaan]

Another train of thought:
web editor supports a CLI option or env var at webapp startup time to set an access token to be used automatically when user visits the web app (so login could be skipped because there is already an access token).

Interested uses could then run a "personal" instance of the web editor on their own system (e.g. through docker) with an access token that is produced "out of band" in some way (e.g. with a startup script that uses client credentials).
With this approach, there is no responsibility for the web editor itself to support/manage client credentials.

[m-mohr]

@soxofaan That would mean the access token would be pretty much valid until it's revoked. Where's the difference just to have a client ID for AuthCode+PKCE that creates such access tokens (or refresh tokens) with infinite validtity time span?

[soxofaan]

That would mean the access token would be pretty much valid until it's revoked

indeed, but I think that is fine in the solution path where the access token was obtained outside of the scope of the web editor itself.

Where's the difference just to have a client ID for AuthCode+PKCE that creates such access tokens

I'm not completely sure I understand your question here, but with OIDC AuthCode flow the web editor obtains tokens that identify the user, while the with the client credentials flow (as feature-requested here), you get tokens that identify the client, which is a different entity. Client credentials flow is the only way to get to that identity.

[m-mohr]

Found a client library that we could potentially migrate to: https://github.com/panva/openid-client