OAuth 2.0 – Basics

This page explains the basics of OAuth 2.0 in the context of the OPC Router. It serves as a common reference for all plug-ins that support OAuth 2.0 authentication (e.g., REST Client and Email) and provides a centralized explanation of recurring terms and procedures.

OAuth 2.0 is a standard that allows an application to authenticate with a target system without sending a static password. Instead, it obtains a time-limited access token from a central authority and uses it to authenticate itself to the target system.

Roles

In the context of the OPC router, there are three roles involved:

Role	Description	In the OPC Router
Client	Requests the token and uses it.	The OPC Router or the respective plug-in.
Authorization Server	Issues the access token after successful login.	The token endpoint of the identity provider (e.g., Microsoft Entra ID).
Resource Server	Verifies the token and returns the actual data.	The connected target system (e.g., REST API or mail server).

Client Credentials Flow (Plug-in Connections)

The Client Credentials Flow is the standard procedure for plug-in connections: The OPC Router logs in as a registered application—without requiring interactive user login. At runtime, the OPC Router runs unattended without a browser through which a user could log in.

1. The OPC Router sends the client ID, client secret, and scope to the token endpoint (grant_type=client_credentials).
2. The authorization server responds with an access token and its expiration time.
3. The OPC Router calls the target system and includes the token in the HTTP header Authorization: Bearer <access_token>.
4. If the token expires, the process is repeated.

Terminology

Term	Meaning
Tenant ID	Unique identifier for the tenant (directory) at the identity provider. Assigns the login to the correct tenant; particularly relevant for Microsoft Entra ID.
Client ID	Unique application identifier for the registered client. Identifies the application to the authorization server.
Client Secret	Secret used by the registered client for authentication at the token endpoint. Stored in the OPC Router as a secret.
Authority URI	Base address of the identity provider from which the specific endpoints (including the token endpoint) are derived.
Token URL	Specific endpoint where the access token is requested.
Redirect URI	Address to which the authorization server redirects the user after an interactive login. Relevant only for user-bound procedures; not for the Client Credentials Flow.
Scopes	List of requested permissions. They must match the client’s registration and the target system.
Access Token	Time-limited token that the application sends to the target system as proof.

Authorization Code Flow (Login to Web Management)

The Authorization Code Flow is an interactive process: A user logs in to the identity provider in the browser; only then is a token issued. In the OPC Router, this applies exclusively to the administrator’s login to Web Management (the configuration interface)—for example, via single sign-on using Microsoft Entra ID (see Establishing the connection to Microsoft Entra ID/Azure AD ). In conjunction with OpenID Connect (OIDC), the identity provider also provides an ID token that describes the logged-in user.

note

This flow applies only to interactive login to Web Management. A plug-in connection runs unattended at runtime and without a browser—interactive login is not possible for it. Instead, plug-ins use the Client Credentials Flow or a token they have previously retrieved themselves.

1. Web Management redirects the user’s browser to the authorization server (with client ID, redirect URI, and scope).
2. The user logs in and confirms the requested permissions.
3. The authorization server redirects the browser back to the redirect URI and returns an authorization code.
4. Web Management exchanges this code, along with the client secret, at the token endpoint for an access token (and, in the case of OIDC, an ID token as well).

Differences from Basic Authentication

With Basic Authentication, the client sends the username and password (Base64-encoded) with every request. There is no token, no expiration time, and no fine-grained permissions.

OAuth 2.0, on the other hand, separates the login process (a one-time process at the token endpoint) from usage (an access token is required for every request). The token is time-limited and restricted to specific permissions via scopes. The password itself is not transferred to the target system.

Configuration in the OPC Router

Depending on the plug-in, OAuth 2.0 is provided in two ways:

• Natively configured: The plug-in has its own fields for the flow. In the email plug-in , for example, you enter the token URL, client ID, client secret, tenant ID, and OAuth scopes directly; the plug-in handles the token retrieval.
• Manual configuration: With the REST client , you retrieve the token yourself via a REST call as needed and pass it on as a bearer token. A complete example is available at Connection with Bearer Token .

Examples

Microsoft 365 / Entra ID

For Microsoft 365 or Entra ID environments, register an application in the Microsoft Entra Admin Center, where you will receive the tenant ID, client ID, and client secret. The token endpoint is in the format https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token; a scope value ending in /.default is frequently used. The connection process is described at Connecting Microsoft Entra ID/Azure AD .

Generic OAuth Providers

The same terms apply for other providers. Refer to the documentation for the respective provider to find the token URL, client ID, client secret, and permitted scopes, and then enter them in the plug-in or use them in the REST call.