> ## Documentation Index > Fetch the complete documentation index at: https://docs.cocoondata.com/llms.txt > Use this file to discover all available pages before exploring further. # Konfiguration von Client-Anwendungen Integratoren können anhand der API der Covata-Plattform ihre eigenen Anwendungen entwickeln, um die leistungsstarken, datenzentrierten Sicherheitsfunktionen von Covata direkt nutzen zu können. Covata-Plattform-Administratoren können den Zugriff solcher Anwendungen ihrer Integratoren auf die Ressourcen der Covata-Plattform konfigurieren, indem sie diese Anwendungen bei ihrer Covata-Plattform-Instanz „registrieren“. Der Zugriff auf diese Ressourcen stützt sich auf das [OAuth 2.0-Autorisierungs-Protokoll](http://tools.ietf.org/html/rfc6749), das die Covata-Plattform für die Authentifizierung und Autorisierung verwendet. Aus der Perspektive der Covata-Plattform ist eine Anwendung eines Integrators eine Client-Anwendung, ungeachtet dessen, um welche der folgenden Arten von Anwendungen es sich handelt: * eine serverseitige Webanwendung, * eine als nativ für Mobilgeräte (z. B. Tablets oder Mobiltelefone) konzipierte Anwendung, * eine als nativ für andere Betriebssysteme (z. B. Desktop- oder Laptop-Computer) konzipierte Anwendung oder * eine Anwendung auf Basis eines Benutzer-Agenten (die z. B. auf Client-Seite in einem Webbrowser ausgeführt wird). Client-Anwendungen können auf keine Ressourcen der Covata-Plattform zugreifen, solange sie nicht bei der Covata-Plattform [registriert sind](/2.16/de/admin/configuring-client-applications.md#configuring-a-client-application). ![Seite Client-Anwendungen](https://mintcdn.com/cocoondata/UCzlmDjgVturBxhL/images/9171fc32a778-client-applications-page.png?fit=max\&auto=format\&n=UCzlmDjgVturBxhL\&q=85\&s=eddc26d734c4f181250859d942646e36) ## Konfiguration einer Client-Anwendung Über die Seite **Client-Anwendungen** der Covata-Verwaltung (oben) können die folgenden Maßnahmen ausgeführt werden: * [Registrierung von Client-Anwendungen](/2.16/de/admin/configuring-client-applications.md#registering-a-new-client-application) bei der Covata-Plattform * [Bearbeitung](/2.16/de/admin/configuring-client-applications.md#editing-a-registered-client-application) auf der Covata-Plattform registrierter Client-Anwendungen - z. B. Änderung der zulässigen [Erteilungstypen](/2.16/de/admin/configuring-client-applications.md#grant-types) einer Client-Anwendung * [Deaktivierung oder Reaktivierung](/2.16/de/admin/configuring-client-applications.md#disabling-or-re-enabling-a-client-application) von registrierten Client-Anwendungen - z. B. um den Zugriff einer Client-Anwendung auf Ressourcen der Covata-Plattform zu blockieren (indem die betreffende Anwendung deaktiviert wird). ### Registrierung einer neuen Client-Anwendung **Registrierung einer neuen Client-Anwendung bei der Covata-Plattform:** 1. [Melden Sie sich](/2.16/de/admin/accessing-administration.md#signing-in) bei der Covata-Verwaltung an. 2. Klicken Sie auf die Option **Client-Apps** links auf der [Covata-Verwaltung-Oberfläche](/2.16/de/admin/accessing-administration.md#the-administration-interface), um die Seite **Client-Anwendungen** aufzurufen. 3. Klicken Sie auf die Schaltfläche **Neue hinzufügen**. 4. Füllen Sie im Dialogfeld **Client-Anwendung hinzufügen** die (in der [Tabelle](/2.16/de/admin/configuring-client-applications.md#client-application-fields) unten detailliert beschriebenen) Felder aus, um die Client-Anwendung zu registrieren. 5. Klicken Sie auf **Speichern**, und die neue Client-Anwendung erscheint als neue Eintragung auf der Seite **Client-Anwendungen**. ### Bearbeitung einer registrierten Client-Anwendung **Bearbeitung auf der Covata-Plattform registrierter Client-Anwendungen:** 1. [Melden Sie sich](/2.16/de/admin/accessing-administration.md#signing-in) bei der Covata-Verwaltung an. 2. Klicken Sie auf die Option **Client-Apps** links auf der [Covata-Verwaltung-Oberfläche](/2.16/de/admin/accessing-administration.md#the-administration-interface), um die Seite **Client-Anwendungen** aufzurufen. 3. Blättern Sie zur gewünschten Client-Anwendung (falls erforderlich) und klicken Sie auf den Link **Bearbeiten**. 4. Ändern Sie im Dialogfeld **Client-Anwendung bearbeiten** die (in der [Tabelle](/2.16/de/admin/configuring-client-applications.md#client-application-fields) unten detailliert beschriebenen) Felder für die registrierte Client-Anwendung. 5. Klicken Sie auf **Speichern**, und die registrierte Client-Anwendung wird aktualisiert. Die folgende Tabelle beschreibt alle Pflichtfelder, die ausgefüllt werden müssen, um eine Anwendung bei der Covata-Plattform zu registrieren. > [!TIP] > > Die in der [folgenden Tabelle](/2.16/de/admin/configuring-client-applications.md#client-application-fields) enthaltenen Informationen können für Integratoren hilfreich sein, die anhand der API der Covata-Plattform Client-Anwendungen entwickeln. | Feld | Beschreibung | | - | - | | Client-ID | Der Wert „Client-ID/Client-Identifikator“ der Client-Anwendung. Dieser Wert bildet zusammen mit dem geheimen **Client-Schlüssel** (siehe unten) die „Client-Anmeldeinformationen“ der Anwendung, die für die OAuth 2.0-Authentifizierung und Autorisierung erforderlich sind, wenn sich ein Covata-Benutzer (mit seinen eigenen „Benutzer-Anmeldeinformationen“) bei der Covata-Plattform authentifiziert. Für weitere Informationen über diese Begriffe siehe die Definition für [Erteilungstyp\*\*](/2.16/de/admin/configuring-client-applications.md#grant-type-explanation) (unten). Wenn ein Covata-Plattform-Administrator [eine neue Client-Anwendung registriert](/2.16/de/admin/configuring-client-applications.md#registering-a-new-client-application), generiert die Covata-Plattform automatisch eine Client-ID auf der Basis eines [Universally Unique Identifier (UUID)](http://tools.ietf.org/html/rfc4122). Der Covata-Plattform-Administrator kann diesen Wert der Client-ID jedoch überschreiben. **Hinweise:** Der Wert der Client-ID: • ist im Allgemeinen in die Client-Anwendung fest einprogrammiert, da er während der meisten OAuth 2.0-Authentifizierungs- und Autorisierungsabläufe an die Covata-Plattform weitergegeben wird. • muss in Beziehung auf alle bei der Covata-Plattform registrierten Client-Anwendungen eindeutig sein. Siehe die Abschnitte [Client-Typen](http://tools.ietf.org/html/rfc6749#section-2.1) und [Client-Identifikator](http://tools.ietf.org/html/rfc6749#section-2.2) der Spezifikation für das [OAuth 2.0-Autorisierungs-Protokoll](http://tools.ietf.org/html/rfc6749) für weitere Informationen über Client-IDs und ihre Verwendung bei Client-Anwendungen. In dieser Spezifikation bezieht sich „Client“ auf eine Client-Anwendung und der „Autorisierungs-Server“ auf die Covata-Plattform. | | Geheimer Client-Schlüssel | Der Wert „Geheimer Client-Schlüssel“ der Client-Anwendung. Dieser Wert bildet zusammen mit der **Client-ID** (siehe oben) die „Client-Anmeldeinformationen“ der Anwendung, die für die OAuth 2.0-Authentifizierung und Autorisierung erforderlich sind, wenn sich ein Covata-Benutzer (mit seinen eigenen „Benutzer-Anmeldeinformationen“) bei der Covata-Plattform authentifiziert. Für weitere Informationen über diese Begriffe siehe die Definition für [Erteilungstyp\*\*](/2.16/de/admin/configuring-client-applications.md#grant-type-explanation) (unten). Wenn ein Covata-Plattform-Administrator [eine neue Client-Anwendung registriert](/2.16/de/admin/configuring-client-applications.md#registering-a-new-client-application), generiert die Covata-Plattform automatisch einen geheimen Client-Schlüssel auf der Basis eines [Universally Unique Identifier (UUID)](http://tools.ietf.org/html/rfc4122). Der Covata-Plattform-Administrator kann diesen Wert des geheimen Client-Schlüssels jedoch überschreiben. **Hinweise:** Wie der Wert der Client-ID ist auch der des geheimen Client-Schlüssels im Allgemeinen fest in die Client-Anwendung einprogrammiert, da er während der meisten OAuth 2.0-Authentifizierungs- und Autorisierungsabläufe an die Covata-Plattform weitergegeben wird. Eine Ausnahme bildet der [implizite OAuth 2.0-Erteilungstyp](/2.16/de/admin/configuring-client-applications.md#implicit-characteristics), bei dem während der Benutzer-Authentifizierung und Autorisierung lediglich der Client-ID-Wert der Anmeldeinformationen der Anwendung an die Covata-Plattform weitergegeben wird. Siehe den Abschnitt [Client-Typen](http://tools.ietf.org/html/rfc6749#section-2.1) und den Unterabschnitt [Client-Passwort](http://tools.ietf.org/html/rfc6749#section-2.3.1) (in [Client-Authentifizierung](http://tools.ietf.org/html/rfc6749#section-2.3)) der Spezifikation für das [OAuth 2.0-Autorisierungs-Protokoll](http://tools.ietf.org/html/rfc6749) für weitere Informationen über geheime Client-Schlüssel und ihre Verwendung bei Client-Anwendungen. In dieser Spezifikation bezieht sich „Client“ auf eine Client-Anwendung und der „Autorisierungs-Server“ auf die Covata-Plattform. | | Anwendungsname | Der Name der Client-Anwendung, den Covata-Benutzer sehen, wenn sie sich über die betreffende Client-Anwendung bei der Covata-Plattform authentifizieren wollen. | | Erteilungstypen | Die [*Erteilung(en) von Autorisierungen*](http://tools.ietf.org/html/rfc6749#section-1.3) (d. h. *Erteilungstyp(en)*), deren Nutzung die Covata-Plattform einer Client-Anwendung gestattet, um der Anwendung einen [*Zugriffs-Token*](http://tools.ietf.org/html/rfc6749#section-1.4) auszustellen. Ein Zugriffs-Token: • definiert die Ressourcen, die einem authentifizierten Covata-Benutzer auf der Covata-Plattform (aufgrund seiner [Rollen](/2.16/de/admin/administering-users.md#a-users-roles)) zur Verfügung stehen. Dies sind im Allgemeinen beliebige sichere Objekte (d. h. verschlüsselte Dateien) oder Sammlungen (d. h. Ordner): • die Benutzer mit [Ersteller-Rolle](/2.16/de/admin/administering-users.md#originator-role) erstellt haben, wodurch der betreffende Benutzer der Besitzer des Elements wird, oder • auf die Benutzer mit [Ersteller-](/2.16/de/admin/administering-users.md#originator-role), [Mitwirkender-](/2.16/de/admin/administering-users.md#collaborator-role) oder [Ad-hoc](/2.16/de/admin/administering-users.md#adhoc-role)-Rolle zugreifen können, weil der Besitzer ihnen das betreffende Element freigegeben hat, • wird der Client-Anwendung von der Covata-Plattform ausgestellt, um der Client-Anwendung Zugriff auf die Ressourcen des Covata-Benutzers (oder öffentliche Ressourcen) auf der Covata-Plattform zu geben, • hat eine begrenzte Lebensdauer. Sobald ein Zugriffs-Token abläuft, hat die Client-Anwendung keinen Zugriff auf die Ressourcen der Covata-Plattform mehr, bis der Benutzer sich bei der Covata-Plattform wieder authentifiziert oder ein [Aktualisierungs-Token](http://tools.ietf.org/html/rfc6749#section-1.5) verwendet wird, um einen neuen Zugriffs-Token zu erhalten. Ein Aktualisierungs-Token kann einer Client-Anwendung von der Covata-Plattform anfänglich nach erfolgreicher OAuth 2.0-Authentifizierung und Autorisierung ausgestellt werden. Wenn der aktuelle Zugriffs-Token abläuft, tauscht die Client-Anwendung diesen Aktualisierungs-Token gegen einen neuen Zugriffs-Token der Covata-Plattform ein (ohne dass sich der Benutzer erneut authentifizieren muss). Die Covata-Plattform unterstützt die folgenden OAuth 2.0-[Erteilungstypen\*\*](/2.16/de/admin/configuring-client-applications.md#grant-type-explanation), die unten vom sichersten bis zum wenigsten sicheren Typ (mit den verschiedenen Client-Anwendungen, die sich für die Implementierung der jeweiligen Erteilungstypen am besten eignen) aufgeführt sind: • **Autorisierungscode** - am besten für die folgenden Client-Anwendungen geeignet: • serverseitige Webanwendungen • native Desktop-/Laptop-Anwendungen oder Anwendungen für Mobilgeräte Für [weitere Informationen](/2.16/de/admin/configuring-client-applications.md#authorization-code-characteristics) über diesen Erteilungstyp siehe die Tabelle [Erteilungstyp-Details](/2.16/de/admin/configuring-client-applications.md#grant-type-details) unten. • **Implizit** - am besten für Anwendungen auf Basis eines Benutzer-Agenten geeignet, die z. B. auf Client-Seite in einem Webbrowser ausgeführt werden.       Für [weitere Informationen](/2.16/de/admin/configuring-client-applications.md#implicit-characteristics) über diesen Erteilungstyp siehe die Tabelle [Erteilungstyp-Details](/2.16/de/admin/configuring-client-applications.md#grant-type-details) unten. • **Passwort** - am besten für die folgenden Client-Anwendungen geeignet: • native Desktop-/Laptop-Anwendungen oder Anwendungen für Mobilgeräte • von Administratoren/Systemen ausgeführte Services (z. B. geplante Jobs). Für [weitere Informationen](/2.16/de/admin/configuring-client-applications.md#password-characteristics) über diesen Erteilungstyp siehe die Tabelle [Erteilungstyp-Details](/2.16/de/admin/configuring-client-applications.md#grant-type-details) unten. \*\* Im Kontext der Covata-Technologien ist ein *Erteilungstyp* (bzw. eine *Erteilung einer Autorisierung* eine Anmeldeinformation, die die *Autorisierung* eines Covata-Benutzers darstellt, auf die gesicherten Ressourcen des betreffenden Benutzers auf der Covata-Plattform zuzugreifen. Diese Anmeldeinformation wird von der Client-Anwendung genutzt, um einen Zugriffs-Token zu erhalten. Die folgenden Konzepte bilden zentrale, für die Erlangung eines Erteilungstyps erforderliche Komponenten: • *Anmeldeinformationen des Benutzers* - aus einer [E-Mail-Adresse](/2.16/de/admin/administering-users.md#email) und dem Passwort eines Covata-Benutzers bestehende Anmeldeinformationen (das Passwort erhält der Covata-Benutzer entweder in der ursprünglichen E-Mail-Benachrichtigung „Covata-Account erstellt“ oder hat der Benutzer selbst geändert) • *Client-Anmeldeinformationen* - aus der [Client-ID](/2.16/de/admin/configuring-client-applications.md#client-id) und dem [geheimen Client-Schlüssel](/2.16/de/admin/configuring-client-applications.md#client-secret) bestehende Anmeldeinformationen | | Gültigkeit des Zugriffs-Tokens | Die Zeit (in Sekunden), die ein von der Covata-Plattform für eine Client-Anwendung ausgestellter Zugriffs-Token gültig bleibt. Nach dem Ablauf des Zugriffs-Token müsste die Client-Anwendung: • entweder der Covata-Plattform einen gültigen Aktualisierungs-Token übermitteln, um einen neuen Zugriffs-Token zu erhalten, oder • vom Covata-Benutzer eine erneute Authentifizierung bei der Covata-Plattform (mit seinen Anmeldeinformationen) verlangen, um einen neuen Zugriffs-Token zu erhalten. **Hinweis:** Für maximale Sicherheit wird empfohlen, die Gültigkeit von Zugriffs-Token relativ kurz zu halten (mit Ablauf innerhalb weniger Minuten bis maximal einigen Stunden). | | Gültigkeit des Aktualisierungs-Tokens | Die Zeit (in Sekunden), die ein von derCovata-Plattform für eine Client-Anwendung ausgestellter Aktualisierungs-Token gültig bleibt. Dieser Wert muss größer sein als der für die Gültigkeit des Zugriffs-Tokens. Läuft ein Aktualisierungs-Token ab, verlangt die Client-Anwendung, dass sich der Covata-Benutzer erneut authentifiziert, um die (dem betreffenden Benutzer verfügbaren) Ressourcen der Covata-Plattform weiterhin nutzen zu können. **Hinweis:** Dieses Feld wird nur von den Erteilungstypen [Autorisierungscode](/2.16/de/admin/configuring-client-applications.md#authorization-code-characteristics) und [Passwort](/2.16/de/admin/configuring-client-applications.md#password-characteristics) genutzt (die unten detaillierter beschrieben sind). | | Eingetragene Weiterleitungs-URI(s) | Eine Liste einer oder mehrerer gültiger Uniform Resource Identifiers (URIs), die die Covata-Plattform nutzt, um den Wert des Parameters [*Weiterleitungs-URI*](http://tools.ietf.org/html/rfc6749#section-3.1.2) (auch *Weiterleitungs-Endpunkt*) zu verifizieren, den die Client-Anwendung der Covata-Plattform (im Rahmen einer OAuth 2.0-Authentifizierung und einer Autorisierungsanfrage für einen Zugriffs-Token) schickt. Entspricht irgendein Teil der von der Client-Anwendung geschickten Weiterleitungs-URI (ab dem Beginn der betreffenden URI) keiner der registrierten, in diesem Feld angegebenen Weiterleitungs-URIs, beendet die Covata-Plattform den Vorgang der OAuth 2.0-Authentifizierung und Autorisierung. **Hinweise:** • Dieses Feld wird nur von den Erteilungstypen [Autorisierungscode](/2.16/de/admin/configuring-client-applications.md#authorization-code-characteristics) und [Implizit](/2.16/de/admin/configuring-client-applications.md#implicit-characteristics) genutzt (die unten detaillierter beschrieben sind), da sich Benutzer bei diesen Erteilungstypen direkt über eine(n) von der Covata-Plattform bereitgestellte(n) Weboberfläche/Benutzeragenten authentifizieren müssen. Die Covata-Plattform leitet den Benutzer-Agenten nach der Authentifizierung zur Weiterleitungs-URI/zum Weiterleitungs-Endpunkt der Client-Anwendung weiter. • Wenn die Client-Anwendung und die Covata-Plattform über das Internet kommunizieren und die Weiterleitungs-URI der Client-Anwendung (der die Covata-Plattform ihre Antwort mit dem Zugriffs-Token schickt) auf dem HTTP-Protokoll basiert, stellen Sie aus Sicherheitsgründen bitte Folgendes sicher: • Diese Weiterleitungs-URI muss für die Nutzung von HTTPS (nicht lediglich HTTP) konfiguriert sein. • Die in diesem Feld angegebenen, registrierten Weiterleitungs-URIs müssen den Präfix `https://` tragen, d. h. keine URIs in diesem Feld sollten den Präfix `http://` tragen. | ## Erteilungstyp-Details Die folgende Tabelle beinhaltet Einzelheiten zu den OAuth 2.0-Erteilungstypen, deren Nutzung die Covata-Plattform Client-Anwendungen gestatten kann (d. h. über die der Anwendung Zugriffs-Token ausgestellt werden). Für eine Erläuterung der von der Covata-Plattform ausgestellten Zugriffs-Token siehe [Erteilungstypen](/2.16/de/admin/configuring-client-applications.md#grant-types) (oben). Die Angaben unten erläutern die verschiedenen Informationen, die zwischen der Client-Anwendung und der Covata-Plattform ausgetauscht werden, den Modus, über den dieser Austausch stattfindet, und damit die Auswirkungen auf die Sicherheit einer Implementierung dieser Erteilungstypen in einer Client-Anwendung. | Erteilungstyp | Details | | - | - | | Autorisierungscode | Der [Erteilungstyp](/2.16/de/admin/configuring-client-applications.md#grant-types) Autorisierungscode handhabt die sichere Übermittlung der Anmeldeinformationen des Benutzers und Clients sowie der Zugriffs- und Aktualisierungs-Token zwischen der Client-Anwendung und der Covata-Plattform. Die Covata-Plattform authentifiziert sowohl den Benutzer als auch die Client-Anwendung mit ihren jeweiligen Anmeldeinformationen. Benutzer-Anmeldeinformationen werden nie an die Client-Anwendung übergeben, da sich Benutzer direkt über eine von der Covata-Plattform bereitgestellte Weboberfläche authentifizieren. Von der Covata-Plattform (nach der erfolgreichen Authentifizierung des Benutzers) an die Client-Anwendung übermittelte Zugriffs-/Aktualisierungs-Token können dann von der Client-Anwendung eingesammelt werden. Dies schränkt die Fähigkeit des Covata-Benutzers ein, selbst auf Zugriffs-/Aktualisierungs-Token zuzugreifen. Dementsprechend gilt Folgendes: • Dies ist der *sicherste* (und daher empfohlene) OAuth 2.0-Erteilungstyp für die Implementierung in einer Client-Anwendung. • Der Erteilungstyp Autorisierungscode sollte in Client-Anwendungen implementiert werden, bei denen es sich um [serverseitige Webanwendungen](http://tools.ietf.org/html/rfc6749#section-2.1) handelt, da diese Anwendungen ihren Quellcode (und daher ihre Client-Anmeldeinformationen) vertraulich halten können. Da die Vertraulichkeit von Client-Anmeldeinformationen von der Client-Anwendung selbst gewährleistet werden kann, werden diese Anwendungen als „vertrauliche Clients“ bezeichnet. • Dieser Erteilungstyp kann auch in „[nativen](http://tools.ietf.org/html/rfc6749#section-2.1)“ Client-Anwendungen implementiert werden, z. B. mobilen oder Desktop-Anwendungen. Es wird jedoch davon ausgegangen, dass Client-Anmeldeinformationen bei diesen Anwendungen nicht sicher sind, sondern extrahiert werden können. Da die Vertraulichkeit von Client-Anmeldeinformationen von der Client-Anwendung nicht selbst gewährleistet werden kann, werden diese Anwendungen als „öffentliche Clients“ bezeichnet. **Hinweis:** *Es wird aus dem folgenden Grund nicht empfohlen, in nativen Anwendungen auf Client-Anmeldeinformationen als Sicherheitsmaßnahme zu vertrauen*: • Da eine native Client-Anwendung ein „öffentlicher Client“ ist, kann die Covata-Plattform die Authentizität der echten Client-Anwendung anhand der Anmeldeinformationen nicht verifizieren, wenn die Client-Anmeldeinformationen der Anwendung extrahiert und in einer nicht autorisierten Client-Anwendung implementiert werden. Wenn die Anmeldeinformationen eines Covata-Benutzers (der auf die echte Client-Anwendung zugreift) auf anderen Wegen (z. B. Phishing) beschafft und dann verwendet werden, um sich über die nicht autorisierte Client-Anwendung bei der Covata-Plattform zu authentifizieren, könnte die nicht autorisierte Anwendung Zugriff auf die (dem betreffenden Benutzer verfügbaren) Ressourcen der Covata-Plattform erhalten. Verlässt sich ein Integrator für die Sicherheit der nativen Anwendung auf Client-Anmeldeinformationen (was nicht empfohlen wird) und kommt der Verdacht auf, dass diese Anmeldeinformationen gestohlen wurden, müsste, um diese Sicherheitsverletzung unverzüglich zu beheben, die Client-Anwendung des Integrators [deaktiviert](/2.16/de/admin/configuring-client-applications.md#disabling-or-re-enabling-a-client-application) werden, um alle nicht autorisierten Client-Anwendungen (in denen diese gestohlenen Client-Anmeldeinformationen implementiert sind) am Zugriff auf die Covata-Plattform zu hindern. Leider sperrt diese Maßnahme auch alle echten Installationen von Client-Anwendungen. Die Client-Anwendung kann daher nach einer Rekonfiguration der registrierten Client-Anwendung mit neuen Client-Anmeldeinformationen (sowie nach einem Rebuild und Roll-out einer neuen Version der echten Client-Anwendung mit den neuen Client-Anmeldeinformationen) auf der Covata-Plattform [reaktiviert](/2.16/de/admin/configuring-client-applications.md#disabling-or-re-enabling-a-client-application) werden. | | Implizit | Der implizite [Erteilungstyp](/2.16/de/admin/configuring-client-applications.md#grant-types) handhabt die sichere Übermittlung der Anmeldeinformationen des Benutzers zwischen der Client-Anwendung und der Covata-Plattform. Die Covata-Plattform authentifiziert den Benutzer mit seinen Anmeldeinformationen. Als Teil des OAuth 2.0-Protokolls wird die Client-Anwendung jedoch bei diesem Erteilungstyp nicht authentifiziert; die Covata-Plattform verifiziert lediglich die Identität der Client-Anwendung anhand der [Client-ID](/2.16/de/admin/configuring-client-applications.md#client-id). Während die Benutzer-Anmeldeinformationen nie an die Client-Anwendung übergeben werden, da sich Benutzer direkt über eine von der Covata-Plattform bereitgestellte Weboberfläche authentifizieren, wird der Zugriffs-Token (im Gegensatz zum Erteilungstyp Autorisierungscode) von der Covata-Plattform in einem URI-Fragment direkt an die Client-Anwendung übermittelt. Dementsprechend gilt Folgendes: • Dieser OAuth 2.0-Erteilungstyp ist bei der Implementierung in einer Client-Anwendung aus den folgenden Gründen *weniger sicher* (als der [Autorisierungscode](/2.16/de/admin/configuring-client-applications.md#authorization-code-characteristics) oben): • Da die Covata-Plattform die Client-Anwendung nicht authentifiziert, kann die Covata-Plattform die Authentizität der Client-Anwendung nicht verifizieren. • Da der Zugriffs-Token im von der Covata-Plattform übermittelten URI-Fragment verfügbar ist, kann der Zugriffs-Token unbefugten Parteien zur böswilligen Nutzung übergeben werden, u. a. für eine Attacke über einen authentifizierten Covata-Benutzer (z. B. durch Phishing). In diesen Fällen ist es möglich die Zugriffs-/Aktualisierungs-Token des Benutzers (d. h. seine Sitzungen) [ablaufen zu lassen](/2.16/de/admin/administering-users.md#expiring-users-tokens-sessions). • Aufgrund des diesem Erteilungstyp inhärenten Risikos, dass Zugriffs-Token unbefugten Parteien übergeben werden können, werden bei Verwendung des impliziten Erteilungstyps keine Aktualisierungs-Token ausgestellt. • Der implizite Erteilungstyp wird im Allgemeinen von Client-Anwendungen implementiert, die „[auf Basis eines Benutzer-Agenten](http://tools.ietf.org/html/rfc6749#section-2.1) wie z. B. Webbrowser-Anwendungen ausgeführt werden, bei denen ausführbarer Code heruntergeladen und im Browser selbst ausgeführt wird (statt auf einem Server), da die Client-Anmeldeinformationen dem Covata-Benutzer zur Verfügung stehen. Die Implementierung des impliziten Erteilungstyps in einer Webbrowser-Anwendung kann die nahtlose Integration der Covata-Benutzer-Authentifizierung und Autorisierung über OAuth 2.0 bei gleichzeitiger Sicherung der Benutzer-Anmeldeinformationen ermöglichen. | | Passwort | Der [Erteilungstyp](/2.16/de/admin/configuring-client-applications.md#grant-types) Passwort delegiert die Handhabung der Benutzer-Anmeldeinformationen an die Client-Anwendung selbst. Sowohl die Benutzer- als auch die Client-Anmeldeinformationen werden der Covata-Plattform von der Client-Anwendung zur Authentifizierung übermittelt. Von der Covata-Plattform (nach der erfolgreichen Authentifizierung des Benutzers) an die Client-Anwendung übermittelte Zugriffs-/Aktualisierungs-Token können dann von der Client-Anwendung eingesammelt werden. Dies schränkt die Fähigkeit des Covata-Benutzers ein, selbst auf Zugriffs-/Aktualisierungs-Token zuzugreifen. Beachten Sie hierbei Folgendes: • Dieser OAuth 2.0-Erteilungstyp ist bei der Implementierung in einer Client-Anwendung *weniger sicher* (als der Erteilungstyp [Autorisierungscode](/2.16/de/admin/configuring-client-applications.md#authorization-code-characteristics) und der [implizite](/2.16/de/admin/configuring-client-applications.md#implicit-characteristics) Erteilungstyp oben), weil die delegierte Handhabung der Benutzer-Anmeldeinformationen in der Client-Anwendung das Risiko erhöht, dass diese Anmeldeinformationen unbefugten Parteien für eine etwaige böswillige Nutzung übergeben werden. Das Risiko einer Übergabe von Benutzer-Anmeldeinformationen an die Client-Anwendung wird durch die Tatsache minimiert, dass diese Anmeldeinformationen nur einmal (für nur eine Anfrage der Client-Anwendung) verwendet und gegen einen Zugriffs-Token eingetauscht werden müssen. Da dieser Erteilungstyp Aktualisierungs-Token für neue Zugriffs-Token ausstellen kann (was empfohlen wird), brauchen die Client-Anwendungen keine Benutzer-Anmeldeinformationen zu speichern. • Der Erteilungstyp Passwort sollte nur von [nativen](http://tools.ietf.org/html/rfc6749#section-2.1) Client-Anwendungen implementiert werden (d. h. mobilen oder Desktop-Anwendungen), wo von hohem Vertrauen zwischen dem Covata-Benutzer und der Client-Anwendung selbst ausgegangen werden kann. Dies sind Client-Anwendungen, die: • Teil des Betriebssystems bilden, auf dem sie ausgeführt werden (d. h. die von derselben Organisation oder Gruppe entwickelt wurden wie das Betriebssystem, auf dem sie ausgeführt werden), • mit einem hohen Level an Privilegien ausgeführt werden oder • von Covata entwickelt wurden. Sofern die Client-Anwendung dieses Vertrauenskriterium erfüllt, könnte der Erteilungstyp Passwort auch in Client-Anwendungen implementiert werden, für die der sicherere Erteilungstyp [Autorisierungscode](/2.16/de/admin/configuring-client-applications.md#authorization-code-characteristics) weder verfügbar noch geeignet ist. | ## Deaktivierung und Reaktivierung einer Client-Anwendung Die Deaktivierung einer registrierten Client-Anwendung verhindert, dass jegliche Installationen der Client-Anwendung auf die Covata-Plattform zugreifen können. Dies ist hilfreich, wenn der Zugriff einer Client-Anwendung auf die Covata-Plattform (vorübergehend oder permanent) deaktiviert werden muss oder wenn Verdacht besteht, dass die Anmeldeinformationen der Client-Anwendung gestohlen wurden. **Deaktivierung, Aktivierung und Reaktivierung auf der Covata-Plattform registrierter Client-Anwendungen:** 1. [Melden Sie sich](/2.16/de/admin/accessing-administration.md#signing-in) bei der Covata-Verwaltung an. 2. Klicken Sie auf die Option **Client-Apps** links auf der [Covata-Verwaltung-Oberfläche](/2.16/de/admin/accessing-administration.md#the-administration-interface), um die Seite **Client-Anwendungen** aufzurufen. 3. Gehen Sie anschließend wie folgt vor: * *Zur Deaktivierung der Client-Anwendung* - klicken Sie auf die grüne Schaltfläche **Aktiviert** (in der Spalte **Status** rechts), sodass diese Schaltfläche auf rot wechselt und als **Deaktiviert** angezeigt wird. * *Zur Aktivierung oder Reaktivierung der Client-Anwendung* - klicken Sie auf die rote Schaltfläche **Deaktiviert** (in der Spalte **Status** rechts), sodass die Schaltfläche auf grün wechselt und als **Aktiviert** angezeigt wird. > [!NOTE] > > Eine Client-Anwendung kann auch bearbeitet werden, wenn sie deaktiviert ist. Diese Funktion ermöglicht es, registrierte Client-Anwendungen zu konfigurieren, ehe ihr Zugriff auf die Covata-Plattform aktiviert wird. *** #### Bitte hinterlassen Sie uns hier Ihr Feedback. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.