Login Issues openeo R-client dev version

openEO Platform Clients
,
1

Hi,

When using the latest openeo R-package dev version (1.2) we suddenly have issues with our login credentials. We switched to this version to make use of the filtering options.
Now when using the login function with our client_id and secret we get the message:
“Login failed. Reason: OAuth failure [invalid_client]
• Bad client credentials”

This is the code used:

host = "https://openeo.cloud"
con = openeo::connect(host)

client_id = ""
secret = ""

openeo::login(
             provider = "egi"
            , config = list(
                client_id = id
                , secret = secret
                , grant_type = "authorization_code"
                , scopes = c(
                    "openid"
                    , "email"
                    , "eduperson_entitlement"
                    , "offline_access"
                )
            )
        )

In the browser we still get the message that authentication has been completed and the client is listed as approved service in EGI.

Thanks for any help as always!

2

Hi Hendrik,
in the dev version we switched to the DeviceCode+PKCE authentication method. So client_id and secret are not needed anymore. I’m setting up a snippet of how it should work. But I guess @florian.lahn has one, probably also documented somewhere already. You’ll get a response soon :wink:
Thanks for reporting, as always!

3

@datascience, can you try this:

#remotes::install_github(repo="Open-EO/openeo-r-client", dependencies=TRUE, ref="develop")
library(openeo)

# connect and login in one step
host = "https://openeo.cloud"
con = connect(host, provider = "egi")

# connect and login seperate
# con = connect(host)
# login(provider="egi")

# check that it works
openeo::describe_account()

In your browser the login-page from your organization will open. Login there. In your R-session you will receive a code. A browser window from EGI will open. Copy this code and submit.

Let us know if this works for you!

P.S: We haven’t added this to the openeo.cloud documentation yet since we are waiting for some httr2 pull requests to be accepted, which would ease the submission of the current dev version to CRAN.

4

Thanks for the quick answer and explanation. Works perfectly!

5

Hi,

to follow up on this, will this method be the new default for OIDC login?
While it works fine in an interactive environment, we have issues with this when writing R-functions to automate our workflows, associated unit tests and also potentially with shiny integrations and/or dockerized services. At least for unit testing of our functions we are so far using the basic authentication, but this does not help when we really need to process data.
We’ve already mentioned this in a separate post (Non-interactive authentication), not sure where it is best to follow on with this topic.
It would definitely be great to have something non-interactive using tokens or ssh-keys.

Any suggestions?
Thanks and all the best!

6

Hi,

regarding the OIDC login. Yes, this is currently the default and preferred way for openEO Platform, at least to my knowledge. All the authentication methods that are considered by openEO platform always require a user interaction for security reasons (maybe also for billing at a later stage). As I’m not part of the main openEO Platform team, I don’t know about the internal development directions and if it is an option to offer more authentication methods for machine access. So, you best advised to push this issue in the separate post you mentioned, as I as the R package maintainer just follow the openEO API specification.

It is probably a really “hacky” temporary solution, but during development and testing the R client, I recently started to save the authenticated connection to disk with saveRDS and after package rebuild I use readRDS to restore the old connection (only works of course if I haven’t changed the client class in the development). When I say “hacky”, I mean that there is no guarantee that it will work infinetly. I have observed that the tokens for the device code flow are quite long lived (several hours). Maybe this can be a temporary solution for this and helps to move forward with your project.

Best Regards,
Florian

7

@florian.lahn I’m not 100% sure, but shouldn’t the old authentication method still work? It feels like we need to look into details and may need to issue a bug fix.