REST Client: Login Options

This page describes the available login options for the REST client plug-in. The option you should use depends on the requirements of the target system.

The general configuration of the plug-in is described on the page REST Client .

For a general introduction to OAuth 2.0 terminology and procedures, see OAuth 2.0 – Basics.

Overview

Login	Description	Typical Use
None	The plug-in does not perform any login.	For publicly accessible endpoints or when authentication information is dynamically passed in the actual REST call.
HttpBasic	The plug-in sends the username and password via HTTP Basic Authentication.	For RESTful web services with traditional username/password login via the HTTP header Authorization.
Jwt	The plug-in sends a JSON Web Token for authentication.	If the target system expects a JWT directly.
OAuth1	The plug-in uses OAuth 1 for login.	For RESTful web services that still require OAuth 1.
OAuth2-RequestHeader	The plug-in sends the OAuth 2 token in the HTTP header.	If the target system expects a bearer token in the header.
OAuth2-UriQueryParameter	The plug-in passes the OAuth 2.0 token as a query parameter in the URL.	If the target system explicitly expects the token in the URL.
Negotiate (process identity)	The plug-in uses the identity of the running process for authentication.	For integrated Windows authentication, if the RESTful web service supports it.
Digest	The plug-in uses HTTP Digest Authentication.	For RESTful web services that require Digest Authentication.

Notes on the variants

None

Use None if no login is required or if you do not want the authentication information to be stored permanently in the plug-in.

This is particularly relevant for dynamically generated tokens.

HTTP Basic

This method is suitable for target systems that require fixed credentials consisting of a username and password.

Additional Properties:

Property	Description
Username	Username for logging in to the RESTful web service.
Password	Password or password reference for the specified user.

JWT

This variant is suitable for target systems that expect a hard-coded JSON Web Token.

Additional Properties:

Property	Description
Access Token	JSON Web Token hard-coded in the plug-in. This option is only suitable if the token can be stored statically.

Note: If the token must first be queried or regularly renewed, use the option None instead of Jwt and pass the current value dynamically in the REST call.

OAuth1

This option is only required if the target system still uses OAuth 1.

Additional Properties:

Property	Description
Signature Method	Signing method for OAuth 1. The example shown uses HmacSha1. The required value depends on the target system and directly affects how the OAuth signature is calculated. A different value may result in the login being rejected even if the credentials are correct.
Parameter Handling	Specifies how the OAuth parameters are transferred. In the example shown, they are sent via the HTTP Authorization header. Which option is allowed depends on the target system’s implementation.
Signature Handling	Specifies how signature characters are handled. In the example shown, Escaped is used. This setting is relevant when special characters or URL-encoded characters are included in the signature calculation.
Realm	In OAuth 1, this specifies the scope or scope of the login. If the RESTful web service specifies a realm, this value must be entered accordingly. If no specific realm is required, the field can be left blank.

Note: If the OAuth credentials are not to be hard-coded but must first be determined at runtime, use the option None instead of OAuth1 and pass the required values dynamically in the REST call.

OAuth2 Request Header

This option is suitable for target systems that expect the OAuth 2.0 token in the HTTP header.

Additional Properties:

Property	Description
Access Token	OAuth 2.0 access token sent in the header.
Token Type	Type identifier placed before the access token in the header. Typically, this is Bearer, resulting in a header such as Authorization: Bearer <Access-Token>. The value is not the token itself, but describes how it is transmitted in the header.

Note: If the access token must be queried initially or renewed periodically, use the option None instead of OAuth2-RequestHeader and pass the current token dynamically in the REST call. An example of this approach is described on the page Connection with Bearer Token .

OAuth2 URI Query Parameters

This method is suitable for target systems that expect the OAuth 2.0 token as a query parameter.

Additional Properties:

Property	Description
Access Token	OAuth 2.0 access token appended to the URL as a query parameter.

Note: If the access token must be queried first or renewed periodically, use the option None instead of OAuth2-UriQueryParameter and pass the current value dynamically in the REST call.

Negotiate (process identity)

With this option, the plug-in authenticates using the identity of the process under which the OPC Router is running. This method does not display any additional properties. Login occurs using the process identity under which the OPC Router is running. Which identity is actually used therefore depends directly on the user account or service account under which the OPC Router is running.

Digest

This method is suitable for target systems that require HTTP Digest Authentication.

Additional Properties:

Property	Description
Username	Username for digest authentication on the RESTful web service.
Password	Password or password reference for the specified user.

Dynamic OAuth Credentials

Instructions for dynamic data transfer are provided directly in the relevant variant sections. As a general rule: If OAuth credentials or tokens must first be queried or regularly renewed, use the “None” option in the REST client plug-in and pass the current values dynamically in the REST call.

Store the dynamically passed secrets—Client Secret, Access Token—in variables of type Secret String; see Secrets.

A step-by-step example of this procedure is described on the page “: Connection with a Bearer Token” at .

This applies in particular to the following options:

• OAuth1
• OAuth2-RequestHeader
• OAuth2-UriQueryParameter