login: Log in on a specific back-end

View source: R/user.R

loginR Documentation

Log in on a specific back-end


Retrieves the bearer-token from the back-end by sending user name and password to the back-end. This step is usually performed during the 'connect' step. If you are only connected to a back-end in order to explore the capabilities and want to compute something, then you need to log in afterwards.


login(user = NULL, password = NULL, provider = NULL, config = NULL, con = NULL)



the user name


the password


provider object as obtained by 'list_oidc_providers()' or the name of the provider in the provider list. If NULL and provider_type="oidc" then the first available provider is chosen from the list.


named list containing 'client_id' and 'secret' or a path to the configuration file (type JSON). If NULL and provider_type="oidc" the configuration parameters are taken from the default authentication client of the OIDC provider.


connected back-end connection (optional) otherwise active_connection() is used.


Based on the general login type (BasicAuth or OIDCAuth) there need to be different configurations. The basic authentication (if supported) is the simplest login mechanism for which user need to enter their credentials directly as user and password.

For the Open ID connect authentication the user needs to select one of the accepted OIDC providers of list_oidc_providers() as provider. Alternatively the name of the provider suffices. For further configuration, you can pass a named list of values as config or a file path to a JSON file.

There are many different authentication mechanisms for OIDC and OAuth2.0, which OIDC is based on. The 'openeo' package supports currently the authorization_code, authorization_code+pkce, device_code and device_code+pkce (see OIDCAuth). For authorization_code you need to state the client_id and secret in the configuration options. In general the most comfortable available login mechanism is chosen automatically (1. device_code+pkce, 2. device_code 3. authorization_code+pkce, 4. authorization_code). For example, with the device_code flow you normally don't even need to specify any additional configuration.

If you really want to choose the authorization flow mechanism manually, you can add grant_type in the configuration list. You can then use the following values:

  • authorization_code

  • authorization_code+pkce

  • urn:ietf:params:oauth:grant-type:device_code

  • urn:ietf:params:oauth:grant-type:device_code+pkce


a connected and authenticated back-end connection

Configuration options


The client id to use, when authorization code is selected as grant_type


The client secret that matches the client_id to identify and validate this local client towards the identity provider


Manually selected authentication method from the ones stated above.


Manually select the scopes for the authentication method. Note: this is usually filled automatically with the information from the provider object


## Not run: 
# simple connection without login to maybe explore the capabilities of a back-end first
# the URL won't work and is just to demonstrate how to write the code
con = connect(host='http://example.openeo.org',version='1.0.0')

# some back-ends support logging in throug OIDC without any parameters

# basic authentication, credentials are dummy values

# or alternatively the OIDC login
login(provider=provider, config=config)

# with device_code+pkce enabled at the OIDC provider you can even use this

## End(Not run)

openeo documentation built on Nov. 17, 2022, 5:07 p.m.