defines classes for different OpenID connect interaction mechanisms. The classes are modeled in generalized fashion by inheriting functions from IAuth and AbstractOIDCAuthentication.


The openEO conformant back-ends shall offer either a basic authentication and / or an OpenID Connect (OIDC) authentication. The first is covered at BasicAuth. And since OIDC is based on the OAuth2.0 protocol there are several mechanisms defined to interact with an OIDC provider. The OIDC provider can be the back-end provider themselves, but they can also delegate the user management to other platforms like EGI, Github, Google, etc, by pointing to the respective endpoints during the service discovery of the back-end. Normally users would not create those classes manually, but state the general login type (oidc or basic) and some additional information (see login).

This client supports the following interaction mechanisms (grant types):

  • authorization_code

  • authorization_code+pkce

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


During the login process an internet browser window will be opened and you will be asked to enter your credentials. The website belongs to the OIDC provider of the chosen openEO back-end. Meanwhile, the client will start a server daemon in the background that listens to the callback from the OIDC provider. For this to work the user needs to get in contact with the openEO service provider and ask them for a configuration file that will contain information about the client_id and secret. The redirect URL requested from the provider is http://localhost:1410/


This procedure also spawns a temporary web server to capture the redirect URL from the OIDC provider. The benefit of this mechanism is that it does not require a client secret issued from the OIDC provider anymore. However, it will still open the internet browser and asks the user for credentials and authorization.


This mechanism does not need to spawn a web server anymore. It will poll the endpoint of the OIDC provider until the user enters a specific device code that will be printed onto the R console. To enter the code either the URL is printed also to the console or if R runs in the interactive mode the internet browser will be opened automatically.


This mechanism uses a designated device code for human confirmation. It is closely related to the device_code+pkce code flow, but without the additional PKCE negotiation.



The access_token to query password restricted webservices of an openEO back-end


The id_token retrieved when exchanging the access_token at the identity provider


$new(provider, config=NULL, ...)

the constructor for the authentication


Initiates the authentication / login in order to obtain the access_token


Terminates the access_token session and logs out the user on the openEO back-end


queries the OIDC provider for the user data like the 'user_id'


returns the internal authentication client as created from package 'httr2'



the name of an OIDC provider registered on the back-end or a provider object as returned by list_oidc_providers()


either a JSON file containing information about 'client_id' and 'secret' or a named list. Experienced user and developer can also add 'scopes' to overwrite the default settings of the OIDC provider


additional parameter might contain force=TRUE specifying to force the use of a specific authentication flow

See also

openEO definition on Open ID connect

Open ID Connect (OIDC)

OAuth 2.0 Device Authorization Grant

Proof Key for Code Exchange by OAuth Public Clients