Dieses Authentifizierungsverfahren gilt als das sicherste, da die Anwendung die Authentifizierungsanfrage nicht an den Benutzer, sondern an den Vantage-Authorization-Server richtet. Der Authorization-Server authentifiziert anschließend den Benutzer und gibt den Autorisierungscode an den Client zurück.
Um zu verhindern, dass der Autorisierungscode abgefangen wird, verwendet dieses Authentifizierungsszenario eine Sicherheitserweiterung namens PKCE (Proof Key for Code Exchange). Diese Erweiterung funktioniert wie folgt: Für jede Autorisierungsanfrage wird eine kryptografische Zufallszahl erzeugt und in code_verifier gespeichert. Diese wird anschließend verwendet, um einen kryptografisch abgeleiteten Wert zu erzeugen, der in code_challenge gespeichert ist. Dieser neue Wert wird dann an den Authorization-Server gesendet, um einen Autorisierungscode zu erhalten.
Weitere Informationen zu PKCE finden Sie unter diesem Link.
Abrufen des Autorisierungscodes
Um den Authentifizierungsprozess zu starten, leiten Sie den Benutzer an den Authorize-Endpunkt weiter und übergeben dabei die folgenden Parameter:
Die Werte für response_type, scope, productId müssen genau wie oben angegeben sein. Diese Schlüssel – außer response_type – können sich ändern. Erwägen Sie, sie in der Konfiguration zu halten.
Beispielanfrage
Ein Parameter mit dem Namen redirect_uri, der den Bezeichner Ihrer Ressource enthält, wird in OAuth 2.0 verwendet, damit Vantage den Autorisierungscode an Ihre Ressource senden und diesen Code anschließend gegen das Zugriffstoken eintauschen kann, das für die Authentifizierung bei allen nachfolgenden API-Aufrufen erforderlich ist. Bei Verwendung dieser Authentifizierungsmethode muss der Wert des Parameters redirect_uri dem technischen Support von ABBYY bereitgestellt werden, damit er von den Administratoren auf die Allowlist gesetzt wird.
Sobald die mit dem Parameter scope angeforderten Zugriffsberechtigungen als gewährt verifiziert wurden, wird der Browser auf eine spezielle Webseite weitergeleitet, die vom Vantage-Server bereitgestellt wird. Diese Webseite enthält ein Dialogfenster, über das Sie sich mit Ihrem Konto autorisieren. Diese Seite sollte in einem Browser geöffnet werden, der eine sichtbare Adressleiste hat, sodass Sie die Seiten-URL und den Status des SSL-Zertifikats der Verbindung überprüfen können.
Wenn Ihre E-Mail-Adresse mit mehreren Konten in verschiedenen Mandanten verknüpft ist, werden Sie nach Angabe Ihrer E-Mail-Adresse aufgefordert, einen Mandanten auszuwählen und Ihr Kennwort einzugeben. Sie können Ihre Mandantenkennung (den Parameter tokenId) auch direkt über eine der folgenden URLs übergeben:
oder
Sie müssen das Kennwort für Ihr Mandantenkonto eingeben. Nachdem Sie Ihre Zugangsdaten eingegeben haben, wird die Autorisierung serverseitig abgeschlossen, der Anwendung wird Zugriff auf die Vantage-API gewährt, und Sie erhalten den Autorisierungscode in der Antwort auf Ihre Anfrage.
Bitte beachten Sie, dass Vantage-Benutzer, wenn eine Website oder Anwendung diesen Authentifizierungstyp verwendet, dieser Website oder App, die Sie zur Liste der zulässigen Redirect-URLs hinzufügen, in ihrem Namen Zugriff auf die Vantage-API gewähren. Um der Website oder App Zugriff zu gewähren, werden Benutzer aufgefordert, sich mit ihrem Benutzernamen und Kennwort in Vantage zu authentifizieren. Sobald ein Benutzer authentifiziert ist, erhält die Website oder App die folgenden Berechtigungen:
- Verwalten von Datenkatalogen im Vantage-Tenant im Namen des Benutzers,
- Zugriff auf Skills im Vantage-Tenant im Namen des Benutzers,
- Erstellen von und Zugriff auf Vantage-Vorgänge im Namen des Benutzers.
Die Website oder App kann das Kennwort des Benutzers nicht ändern, die Liste der Benutzer in einem Vantage-Tenant nicht ändern oder Skills bearbeiten. Es wird nur Zugriff auf die Vantage-API gewährt. Der Benutzer kann den einmal gewährten Zugriff nicht widerrufen.
Abrufen des Autorisierungs-Tokens
Sobald Sie den Autorisierungscode erhalten haben, haben Sie eine Minute Zeit, ihn gegen das Zugriffstoken einzutauschen. Senden Sie dazu eine POST-Anfrage an den Token-Endpunkt mit Daten im Format application/x-www-form-urlencoded.
Parameter des Anfragetexts:
Beispielanfrage:
Für Windows:
Für Linux:
Die Serverantwort auf Ihre Anfrage enthält das Zugriffstoken:
Weitere Informationen zum Authorization-Code-Flow finden Sie unter diesem Link.
Für jeden Flow enthält der Schlüssel access_token das Token, während der Schlüssel expires_in angibt, nach welcher Zeit (in Sekunden) das Token abläuft. Standardmäßig beträgt die Gültigkeitsdauer eines Access-Tokens 24 Stunden (weitere Informationen finden Sie unter Token lifetimes). Fügen Sie allen Ihren Anfragen den folgenden Authorization-Header hinzu und ersetzen Sie token durch den von Ihnen erhaltenen Wert:
Beachten Sie, dass Sie mehrere Token mit demselben Konto anfordern können. Weitere Informationen zum Autorisierungstoken finden Sie unter diesem Link.
Abrufen des Refresh-Tokens
Wenn die Option Allow issuing refresh tokens to refresh access tokens bei der Konfiguration des Vantage-API-Clients aktiviert war und die Anforderung zum Abrufen des Zugriffstokens den Parameter scope=openid permissions global.wildcard offline_access enthielt, erhalten Sie in der Antwort zusätzlich ein Refresh-Token. Sobald Sie ein Refresh-Token haben, können Sie das Zugriffstoken mit einer POST-Anfrage an den Token-Endpunkt und den folgenden Parametern aktualisieren:
Beispielanfrage:
Für Windows:
Für Linux:
Access- und Refresh-Token sind so konfiguriert, dass sie folgende Laufzeiten haben:
- Laufzeit des Access-Tokens: Definiert den Zeitraum, in dem das ausgegebene Access-Token dem Benutzer Zugriff auf Vantage gewährt. Die Standardlaufzeit eines Access-Tokens beträgt 24 Stunden.
- Laufzeit des Refresh-Tokens: Definiert den absoluten Zeitraum ab der Ausstellung des ersten Access-Tokens, in dem das ausgegebene Refresh-Token verwendet werden kann, um das Access-Token zu erneuern. Die Standardlaufzeit eines Refresh-Tokens beträgt 30 Tage.