> ## 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. Safe Share-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](/3.3/de/admin-platform/configuring-client-applications.md#configuring-a-client-application). ![Seite Client-Anwendungen](https://mintcdn.com/cocoondata/XFCH1-fsOPTworsw/images/a419a8ee34a4-client-applications-page.png?fit=max\&auto=format\&n=XFCH1-fsOPTworsw\&q=85\&s=46e6dc86ae1f8d1f06aabcceab298af0) ## Konfiguration einer Client-Anwendung Über die Seite **Client-Anwendungen** der Safe Share-Verwaltung ([siehe oben](/3.3/de/admin-platform/configuring-client-applications.md#client-applications-page)) können die folgenden Maßnahmen ausgeführt werden: * [Registrierung von Client-Anwendungen](/3.3/de/admin-platform/configuring-client-applications.md#registering-a-new-client-application) bei der Covata-Plattform * Folgende Aktionen für auf der Covata-Plattform registrierte Client-Anwendungen: * [Bearbeitung](/3.3/de/admin-platform/configuring-client-applications.md#editing-a-registered-client-application), z. B. Änderung der zulässigen [Erteilungstypen](/3.3/de/admin-platform/configuring-client-applications.md#grant-types) einer Client-Anwendung, sowie * [Deaktivierung oder Reaktivierung](/3.3/de/admin-platform/configuring-client-applications.md#disabling-or-re-enabling-a-client-application), 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](/3.3/de/admin-platform/accessing-platform-administration.md#signing-in-to-platform-administration) bei der Safe Share-Verwaltung an. 2. Klicken Sie auf die Option **Client-Apps** links auf der [Oberfläche Safe Share-Verwaltung](/3.3/de/admin-platform/accessing-platform-administration.md#the-platform-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](/3.3/de/admin-platform/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**. 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](/3.3/de/admin-platform/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 | | - | - | | Anwendungsname | Der Name der Client-Anwendung, den Covata-Benutzer sehen, wenn sie sich über die betreffende Client-Anwendung bei der Covata-Plattform authentifizieren wollen. | | 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 \*\*](/3.3/de/admin-platform/configuring-client-applications.md#grant-type-explanation) (unten). Wenn ein Safe Share-Administrator [eine neue Client-Anwendung registriert](/3.3/de/admin-platform/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 Safe Share-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 von Benutzern an die Covata-Plattform weitergegeben wird • muss in Beziehung auf alle bei der Covata-Plattform registrierten Client-Anwendungen eindeutig sein. Für weitere Informationen über Client-IDs und ihre Verwendung bei Client-Anwendungen 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). 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 \*\*](/3.3/de/admin-platform/configuring-client-applications.md#grant-type-explanation) (unten). Wenn ein Safe Share-Administrator [eine neue Client-Anwendung registriert](/3.3/de/admin-platform/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 Safe Share-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](/3.3/de/admin-platform/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. Für weitere Informationen über geheime Client-Schlüssel und ihre Verwendung bei Client-Anwendungen 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). In dieser Spezifikation bezieht sich „Client“ auf eine Client-Anwendung und der „Autorisierungs-Server“ auf die Covata-Plattform. | | 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. (Zugriffs-Token sind unter **Erteilungstypen** unten näher beschrieben.) 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 (z. B. mit Ablauf innerhalb weniger Minuten bis maximal 10 Minuten). | | Erteilungstypen | Der/die *Erteilungstyp(en)* (d. h. [*Erteilung(en) von Autorisierungen*](http://tools.ietf.org/html/rfc6749#section-1.3)), dessen/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 zur Verfügung stehen (die von einem [Safe Share-Administrator](/3.3/de/admin-platform/administering-platform-administrator-users.md#platform-administrator-role) oder [Organisations-Administrator](/3.3/de/admin-platform/administering-users-within-an-organisation.md#organisation-administrator-role)) konfiguriert werden können). Diese Ressourcen umfassen zum Beispiel: • beliebige Dateien (d. h. Dateiobjekte/sichere Objekte) oder Ordner (d. h. Sammlungen): • die Benutzer mit [Ersteller-Rolle](/3.3/de/admin-platform/administering-users-within-an-organisation.md#originator-role) erstellt haben, wodurch der betreffende Benutzer der Besitzer des Elements wird, oder • auf die Benutzer mit [Ersteller-](/3.3/de/admin-platform/administering-users-within-an-organisation.md#originator-role), [Mitwirkender-](/3.3/de/admin-platform/administering-users-within-an-organisation.md#collaborator-role) oder [Ad-hoc](/3.3/de/admin-platform/administering-users-within-an-organisation.md#adhoc-role)-Rolle zugreifen können, weil der Besitzer ihnen das betreffende Element freigegeben hat, • Funktionen der [Safe Share-Verwaltung](/3.3/de/admin-platform.md#platform-administration), die für Benutzer mit der [Safe Share-Administrator-Rolle](/3.3/de/admin-platform/administering-platform-administrator-users.md#platform-administrator-role) verfügbar sind • Funktionen der [Safe Share-Organisationsverwaltung](/3.3/de/admin-platform/organisation-administration.md), die für Benutzer mit der [Organisations-Administrator-Rolle](/3.3/de/admin-platform/administering-users-within-an-organisation.md#organisation-administrator-role) verfügbar sind • wird der Client-Anwendung von der Covata-Plattform ausgestellt, um der Client-Anwendung Zugriff auf die Ressourcen des Covata-Benutzers 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 \*\*](/3.3/de/admin-platform/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](/3.3/de/admin-platform/configuring-client-applications.md#authorization-code-characteristics) über diesen Erteilungstyp siehe die Tabelle [Einzelheiten zum Erteilungstyp](/3.3/de/admin-platform/configuring-client-applications.md#grant-type-details) unten. • **Implizit** - am besten für Anwendungen auf Basis eines Benutzer-Agenten geeignet, die z. B. auf der Client-Seite in einem Webbrowser ausgeführt werden.       Für [weitere Informationen](/3.3/de/admin-platform/configuring-client-applications.md#implicit-characteristics) über diesen Erteilungstyp siehe die Tabelle [Einzelheiten zum Erteilungstyp](/3.3/de/admin-platform/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](/3.3/de/admin-platform/configuring-client-applications.md#password-characteristics) über diesen Erteilungstyp siehe die Tabelle [Einzelheiten zum Erteilungstyp](/3.3/de/admin-platform/configuring-client-applications.md#grant-type-details) unten. Das Dialogfeld **Client-Anwendung hinzufügen/bearbeiten** zeigt im Abschnitt **Erteilungstypen** auch die folgenden Optionen. Während diese Optionen selbst keine OAuth 2.0-Erteilungstypen sind, unterstützen sie die (oben genannten) OAuth 2.0-Erteilungstypen: • **Aktualisierungs-Token zulassen** - legt fest, ob die Covata-Plattform der Client-Anwendung Aktualisierungs-Token ausstellen kann, mit denen die Client-Anwendung anschließend neue Zugriffs-Token anfordern kann. Dies ermöglicht es, die Sitzung eines Covata-Benutzers (potenziell unbegrenzt) fortzusetzen, ohne dass der Benutzer sich nach dem Ablauf seines Zugriffs-Token neu anmelden muss. Diese Option ist nur anwendbar wenn der Erteilungstyp **Autorisierungscode** und/oder **Passwort** (siehe oben) gewählt ist/sind. • **Geräteregistrierung zulassen** - legt fest, ob die (auf einem spezifischen Gerät, d. h. meistens auf einer mobilen Plattform wie iOS oder Android ausgeführte) Client-Anwendung einen spezifischen Covata-Benutzer mit einer Kennung authentifizieren kann. Sobald sich ein Covata-Benutzer (anhand seiner E-Mail-Adresse und seines Passworts) über eine auf dem Gerät ausgeführte Client-Anwendung bei der Covata-Plattform authentifiziert, kann der Benutzer eine Kennung einrichten und für die Authentifizierung bei der Covata-Plattform verwenden (ohne dass die E-Mail-Adresse bzw. das Passwort als Anmeldeinformationen benötigt werden). Für maximale Sicherheit ist eine Kennung an einen spezifischen Covata-Benutzer *und* ein spezifisches Gerät gebunden. \*\* Im Kontext von Covata-Technologien stellt ein *Erteilungstyp*/eine *Erteilung einer Autorisierung* als Anmeldeinformation die *Autorisierung* eines Covata-Benutzers dar, auf die geschützten 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 der E-Mail-Adresse und dem Passwort eines Covata-Benutzers bestehende Anmeldeinformationen (das Passwort erhält der Covata-Benutzer entweder in der ursprünglichen E-Mail-Benachrichtigung „*Account erstellt*“, nachdem sein Account über die [Organisationsverwaltung](/3.3/de/admin-platform/administering-users-within-an-organisation.md#adding-an-organisation-user-account) oder [Safe Share-Verwaltung](/3.3/de/admin-platform/administering-platform-administrator-users.md#adding-a-platform-administrator-account) hinzugefügt wurde, oder das er selbst geändert hat). • *Client-Anmeldeinformationen* - aus der [Client-ID](/3.3/de/admin-platform/configuring-client-applications.md#client-id) und dem [geheimen Client-Schlüssel](/3.3/de/admin-platform/configuring-client-applications.md#client-secret) bestehende Anmeldeinformationen | | Gültigkeit des Aktualisierungs-Tokens | Die Zeit (in Sekunden), die ein von der Covata-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 ist nur anwendbar (und verfügbar), wenn die Option **Aktualisierungs-Token zulassen** (bei den **Erteilungstypen** [siehe oben](/3.3/de/admin-platform/configuring-client-applications.md#grant-types)) aktiviert ist, die wiederum nur verfügbar ist, wenn auch die Erteilungstyp-Option(en) **Autorisierungscode** und/oder **Passwort** gewählt ist/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 als *Weiterleitungs-Endpunkt* bezeichnet) 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 ist nur anwendbar (und verfügbar), wenn für den Erteilungstyp die Option(en) **Autorisierungscode** und/oder **Implizit** (bei den **Erteilungstypen** [siehe oben](/3.3/de/admin-platform/configuring-client-applications.md#grant-types)) aktiviert ist/sind, da sich Benutzer bei diesen Erteilungstypen direkt über eine Weboberfläche/einen von der Covata-Plattform bedienten Benutzer-Agenten 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. | ### Einzelheiten zum Erteilungstyp 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](/3.3/de/admin-platform/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](/3.3/de/admin-platform/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. Nach der erfolgreichen Benutzerauthentifizierung können Zugriffs-/Aktualisierungs-Token von der Covata-Plattform sicher an die Client-Anwendung übermittelt werden, ohne dass diese Token einem Browser (d. h. Benutzer-Agent) gegenüber offen gelegt werden. Es gilt daher 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](/3.3/de/admin-platform/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 den Zugriff aller 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](/3.3/de/admin-platform/configuring-client-applications.md#disabling-or-re-enabling-a-client-application) werden. | | Implizit | Der implizite [Erteilungstyp](/3.3/de/admin-platform/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](/3.3/de/admin-platform/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. Es gilt daher Folgendes: • Dieser OAuth 2.0-Erteilungstyp ist bei der Implementierung in einer Client-Anwendung aus den folgenden Gründen *weniger sicher* (als der [Autorisierungscode](/3.3/de/admin-platform/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). • 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](/3.3/de/admin-platform/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](/3.3/de/admin-platform/configuring-client-applications.md#authorization-code-characteristics) und der [implizite](/3.3/de/admin-platform/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 es Client-Anwendungen ermöglicht, Aktualisierungs-Token für neue Zugriffs-Token zu übermitteln (was empfohlen wird), brauchen die Client-Anwendungen keine Anmeldeinformationen von Benutzern 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](/3.3/de/admin-platform/configuring-client-applications.md#authorization-code-characteristics) weder verfügbar noch geeignet ist. | ## Bearbeitung einer registrierten Client-Anwendung **Bearbeitung auf der Covata-Plattform registrierter Client-Anwendungen:** 1. [Melden Sie sich](/3.3/de/admin-platform/accessing-platform-administration.md#signing-in-to-platform-administration) bei der Safe Share-Verwaltung an. 2. Klicken Sie auf die Option **Client-Apps** links auf der [Oberfläche Safe Share-Verwaltung](/3.3/de/admin-platform/accessing-platform-administration.md#the-platform-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](/3.3/de/admin-platform/configuring-client-applications.md#client-application-fields) oben detailliert beschriebenen) Felder für die registrierte Client-Anwendung. 5. Klicken Sie auf **Speichern**, und die registrierte Client-Anwendung wird aktualisiert. ## 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](/3.3/de/admin-platform/accessing-platform-administration.md#signing-in-to-platform-administration) bei der Safe Share-Verwaltung an. 2. Klicken Sie auf die Option **Client-Apps** links auf der [Oberfläche Safe Share-Verwaltung](/3.3/de/admin-platform/accessing-platform-administration.md#the-platform-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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.