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.
a connected and authenticated back-end connection
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
client_id
The client id to use, when authorization code is selected as grant_type
secret
The client secret that matches the client_id to identify and validate this local client towards the identity provider
grant_type
Manually selected authentication method from the ones stated above.
scope
Manually select the scopes for the authentication method. Note: this is usually filled automatically with the information from the provider object
if (FALSE) { # \dontrun{
# 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
login()
# basic authentication, credentials are dummy values
login(user='user',password='password')
# or alternatively the OIDC login
login(provider=provider, config=config)
# with device_code+pkce enabled at the OIDC provider you can even use this
login(provider="your_named_provider")
} # }