OAuth 2.0 – Grundlagen

Diese Seite erklärt die OAuth-2.0-Grundlagen im Kontext des OPC Routers. Sie dient als gemeinsame Referenz für alle Plug-ins, die eine OAuth 2.0-Anmeldung unterstützen (z. B. REST-Client und E-Mail), und erklärt die wiederkehrenden Begriffe und Verfahren einmal zentral.

OAuth 2.0 ist ein Standard, mit dem sich eine Anwendung an einem Zielsystem anmeldet, ohne ein festes Passwort mitzusenden. Stattdessen holt sie sich an einer zentralen Stelle ein zeitlich begrenztes Access Token und weist sich damit gegenüber dem Zielsystem aus.

Rollen

Im OPC-Router-Kontext sind drei Rollen beteiligt:

Rolle	Bedeutung	Im OPC Router
Client	Fordert das Token an und verwendet es.	Der OPC Router bzw. das jeweilige Plug-in.
Authorization Server	Stellt nach erfolgreicher Anmeldung das Access Token aus.	Der Token-Endpunkt des Identity-Providers (z. B. Microsoft Entra ID).
Resource Server	Prüft das Token und liefert die eigentlichen Daten.	Das angebundene Zielsystem (z. B. REST-API oder Mailserver).

Client Credentials Flow (Plug-in-Verbindungen)

Der Client Credentials Flow ist der Standardfall für Plug-in-Verbindungen: Der OPC Router meldet sich als registrierte Anwendung an – ohne interaktive Benutzeranmeldung. Der OPC Router läuft zur Laufzeit im unbeaufsichtigten Betrieb ohne Browser, über den sich ein Benutzer anmelden könnte.

1. Der OPC Router sendet Client ID, Client Secret und Scope an den Token-Endpunkt (grant_type=client_credentials).
2. Der Authorization Server antwortet mit einem Access Token und dessen Gültigkeitsdauer.
3. Der OPC Router ruft das Zielsystem auf und sendet das Token im HTTP-Header Authorization: Bearer <access_token> mit.
4. Läuft das Token ab, wird der Vorgang wiederholt.

Begriffe

Begriff	Bedeutung
Tenant ID	Eindeutige Kennung des Mandanten (Verzeichnisses) beim Identity-Provider. Ordnet die Anmeldung dem richtigen Mandanten zu; relevant vor allem bei Microsoft Entra ID.
Client ID	Eindeutige Anwendungskennung des registrierten Clients. Identifiziert die Anwendung gegenüber dem Authorization Server.
Client Secret	Geheimnis des registrierten Clients zur Authentifizierung am Token-Endpunkt. Wird im OPC Router als Secret hinterlegt.
Authority URI	Basisadresse des Identity-Providers, aus der sich die konkreten Endpunkte (u. a. der Token-Endpunkt) ergeben.
Token URL	Konkreter Endpunkt, an dem das Access Token angefordert wird.
Redirect URI	Adresse, an die der Authorization Server nach einer interaktiven Anmeldung zurückleitet. Nur bei benutzergebundenen Verfahren relevant, nicht beim Client Credentials Flow.
Scopes	Liste der angeforderten Berechtigungen. Sie müssen zur Registrierung des Clients und zum Zielsystem passen.
Access Token	Zeitlich begrenztes Token, das die Anwendung dem Zielsystem als Nachweis mitsendet.

Authorization Code Flow (Anmeldung am Web Management)

Der Authorization Code Flow ist ein interaktives Verfahren: Ein Benutzer meldet sich im Browser am Identity-Provider an, erst danach wird ein Token ausgestellt. Im OPC Router betrifft das ausschließlich die Administrator-Anmeldung am Web Management (der Konfigurationsoberfläche) – etwa per Single Sign-on über Microsoft Entra ID (siehe Microsoft Entra ID/Azure AD anbinden). Zusammen mit OpenID Connect (OIDC) liefert der Identity-Provider zusätzlich ein ID-Token, das den angemeldeten Benutzer beschreibt.

hinweis

Dieser Flow gilt nur für die interaktive Anmeldung am Web Management. Eine Plug-in-Verbindung läuft zur Laufzeit unbeaufsichtigt und ohne Browser – für sie ist keine interaktive Anmeldung möglich. Plug-ins verwenden stattdessen den Client Credentials Flow oder ein zuvor selbst geholtes Token.

1. Das Web Management leitet den Browser des Benutzers zum Authorization Server um (mit Client ID, Redirect URI und Scope).
2. Der Benutzer meldet sich an und bestätigt die angeforderten Berechtigungen.
3. Der Authorization Server leitet den Browser zur Redirect URI zurück und übergibt einen Autorisierungscode.
4. Das Web Management tauscht diesen Code zusammen mit dem Client Secret am Token-Endpunkt gegen ein Access Token (bei OIDC zusätzlich ein ID-Token).

Abgrenzung zu Basic Authentication

Bei der Basic Authentication sendet der Client bei jedem Aufruf Benutzername und Passwort (Base64-kodiert) mit. Es gibt kein Token, keine Ablaufzeit und keine feingranularen Berechtigungen.

OAuth 2.0 trennt dagegen die Anmeldung (einmalig am Token-Endpunkt) von der Nutzung (Access Token bei jedem Aufruf). Das Token ist zeitlich begrenzt und über Scopes auf bestimmte Berechtigungen eingeschränkt. Das Passwort selbst wird nicht an das Zielsystem übertragen.

Konfiguration im OPC Router

Je nach Plug-in wird OAuth 2.0 auf zwei Arten bereitgestellt:

• Nativ konfiguriert: Das Plug-in besitzt eigene Felder für den Flow. Im E-Mail-Plug-in tragen Sie z. B. Token Url, Client ID, Client Secret, Tenant ID und OAuth Scopes direkt ein; den Token-Abruf übernimmt das Plug-in.
• Manuell projektiert: Beim REST-Client holen Sie das Token bei Bedarf selbst über einen REST-Aufruf und reichen es als Bearer-Token weiter. Ein durchgängiges Beispiel steht unter Verbindung mit Bearer Token.

Beispiele

Microsoft 365 / Entra ID

Für Microsoft-365- bzw. Entra-ID-Umgebungen registrieren Sie eine Anwendung im Microsoft Entra Admin Center und erhalten dort Tenant ID, Client ID und Client Secret. Der Token-Endpunkt hat die Form https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token, als Scope wird häufig ein Wert mit der Endung /.default verwendet. Das Anbinden ist unter Microsoft Entra ID/Azure AD anbinden beschrieben.

Generische OAuth-Anbieter

Bei anderen Anbietern gelten dieselben Begriffe. Token URL, Client ID, Client Secret und die zulässigen Scopes entnehmen Sie der Dokumentation des jeweiligen Providers und tragen sie im Plug-in ein bzw. verwenden sie im REST-Aufruf.