OIDCAuth | R Documentation |
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.
access_token
The access_token to query password restricted webservices of an openEO back-end
id_token
The id_token retrieved when exchanging the access_token at the identity provider
$new(provider, config=NULL, ...)
the constructor for the authentication
$login()
Initiates the authentication / login in order to obtain the access_token
$logout()
Terminates the access_token session and logs out the user on the openEO back-end
$getUserData()
queries the OIDC provider for the user data like the 'user_id'
$getAuth()
returns the internal authentication client as created from package 'httr2'
provider
the name of an OIDC provider registered on the back-end or a provider object as returned by list_oidc_providers()
config
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
https://openeo.org/documentation/1.0/authentication.html#openid-connect
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.