Verwenden einer App anstelle einer OAuth app
Im Allgemeinen werden Apps häufiger als OAuth apps verwendet.
Sowohl Apps als auch OAuth apps verwenden OAuth 2.0.
OAuth apps können nur im Namen von Benutzerinnen handeln, während Apps entweder im Namen von Benutzerinnen oder unabhängig von Benutzer*innen handeln können.
Weitere Informationen finden Sie unter Unterschiede zwischen -Apps und OAuth-Apps.
Weitere Informationen zum Migrieren einer vorhandenen OAuth app zu einer App findest du unter Migrieren von OAuth-Apps zu -Apps.
Apps bieten erhöhte Sicherheit
Apps bieten mehr Kontrolle darüber, was die App tun kann. Anstelle des breiten Spektrums der Bereiche von OAuth apps verwenden Apps differenzierte Berechtigungen. Wenn deine App beispielsweise den Inhalt eines Repositorys lesen muss, erfordert eine OAuth app den repo-Bereich, mit dem die App auch den Inhalt und die Einstellungen des Repositorys bearbeiten könnte. Eine App kann schreibgeschützten Zugriff auf Repositoryinhalte anfordern, wodurch die App keine privilegierteren Aktionen wie das Ändern der Repositoryinhalte oder -einstellungen durchführen kann.
Apps bieten auch mehr Kontrolle über den Repositoryzugriff. Mit einer App kann derdie Besitzerin oder Organisationsbesitzerin, derdie die App installiert hat, entscheiden, auf welche Repositorys die App zugreifen kann. Umgekehrt kann eine OAuth app auf jedes Repository zugreifen, auf das derdie Benutzerin, der*die die App autorisiert hat, zugreifen kann.
Apps verwenden kurzlebige Token. Wenn das Token kompromittiert wird, ist das Token für einen kürzeren Zeitraum gültig, wodurch der Schaden verringert wird, der angerichtet werden kann. Umgekehrt laufen OAuth app-Token nicht ab, bis die Person, die die OAuth app autorisiert hat, das Token widerruft.
Diese Sicherheitsfeatures helfen dabei, die Sicherheit deiner App zu härten, indem sie den Schaden begrenzen, der aus dem Kompromittieren der Anmeldeinformationen für deine App entstehen könnte. Darüber hinaus können Organisationen mit strengeren Sicherheitsrichtlinien deine App verwenden.
Apps können unabhängig von Benutzer*innen oder in deren Namen handeln.
Apps können unabhängig von demder Benutzerin agieren. Dies ist von Vorteil für Automatisierungen, die keine Benutzereingabe erfordern.
Ähnlich wie OAuth apps können Apps weiterhin Aktionen im Namen eines Benutzers bzw. einer Benutzerin ausführen. Anders als OAuth apps, die nicht anzeigen, dass die Aktion von der App ausgeführt wurde, geben Apps an, dass die Aktion im Namen des Benutzers bzw. der Benutzerin ausgeführt wurde.
Apps sind nicht mit einem Benutzerkonto verknüpft und belegen keinen Arbeitsplatz. Apps bleiben auch dann installiert, wenn die Person, die die App ursprünglich installiert hat, die Organisation verlässt. Auf diese Weise können deine Integrationen auch dann weiterhin funktionieren, wenn Personen dein Team verlassen.
Apps haben skalierbare Ratenlimits
Das Ratenlimit für Apps, die ein Installationszugriffstoken verwenden, wird mit der Anzahl der Repositorys und der Anzahl der Organisationsbenutzer skaliert. Umgekehrt weisen OAuth apps niedrigere Ratenlimits auf und sind nicht skalierbar. Weitere Informationen finden Sie unter Rate limits for Apps (Ratenbegrenzungen für -Apps).
Apps verfügen über integrierte Webhooks
Apps verfügen über integrierte, zentralisierte Webhooks. Apps können Webhookereignisse für alle Repositorys und Organisationen empfangen, auf die die App zugreifen kann. Umgekehrt müssen OAuth apps Webhooks einzeln für jedes Repository und jede Organisation konfigurieren.
Der API-Zugriff unterscheidet sich geringfügig
Im Allgemeinen können Apps und OAuth apps die gleichen API-Anforderungen ausführen. Es gibt aber einige Unterschiede:
- Die REST-API zum Verwalten von Überprüfungsausführungen und Überprüfungssammlungen ist nur für Apps verfügbar.
- Ressourcen auf Unternehmensebene wie das Unternehmensobjekt selbst sind für Apps nicht verfügbar. Das bedeutet, dass Apps keine Endpunkte wie
GET /enterprise/settings/licenseaufrufen können. Unternehmenseigene Organisations- und Repositoryressourcen sind jedoch verfügbar. - Einige Anforderungen geben möglicherweise unvollständige Daten zurück, abhängig von den Berechtigungen und dem Repositoryzugriff, die einer App gewährt wurde. Wenn deine App beispielsweise eine Anforderung sendet, um alle Repositorys abzurufen, auf die eine Benutzerin zugreifen kann, enthält die Antwort nur die Repositorys, auf die der App ebenfalls Zugriff gewährt wurden.
Weitere Informationen zu den REST-API-Endpunkten für Apps findest du unter Für -App-Installationszugriffstoken verfügbare Endpunkte.
Auswählen zwischen einer App oder einem personal access token
Wenn du im Namen eines Benutzers bzw. einer Benutzerin oder in einer Organisation auf -Ressourcen zugreifen möchtest oder eine langlebige Integration planst, empfiehlt es sich, eine App zu erstellen.
Du kannst personal access tokens für API-Tests oder kurzlebige Skripts verwenden. Da ein personal access token einem bzw. einer Benutzerin zugeordnet ist, kann deine Automatisierung unterbrochen werden, wenn die Benutzerinnen keinen Zugriff mehr auf die benötigten Ressourcen haben. Eine App, die in einer Organisation installiert ist, ist nicht von einemeiner Benutzerin abhängig. Zusätzlich belegt eine App anders als eine benutzende Person keinen Arbeitsplatz.
unterstützt zwei Arten von personal access tokens, empfiehlt jedoch, nach Möglichkeit ein fine-grained personal access token anstelle von personal access tokens (classic) zu verwenden. Weitere Informationen zu personal access tokens findest du unter Verwalten deiner persönlichen Zugriffstoken.
Auswählen zwischen einer App oder Actions
Apps und Actions bieten beide Möglichkeiten zum Erstellen von Automatisierungs- und Workflowtools.
Actions ermöglicht die Automatisierung von Aufgaben wie Continuous Integration, Bereitstellung und Projektmanagement in einem Repository. Sie werden direkt auf mit gehosteten Runnercomputern ausgeführt, die deine Administratorin eingerichtet hat. Actions werden nicht dauerhaft ausgeführt. Actions-Workflows werden als Reaktion auf Ereignisse ausgeführt, die in deinem Repository auftreten, und haben nur Zugriff auf die Ressourcen des Repositorys, für das sie eingerichtet sind. Benutzerdefinierte Aktionen können jedoch für mehrere Repositorys und Organisationen freigegeben werden, sodass Entwickler*innen vorhandene Aktionen wiederverwenden und ändern können, um ihre Anforderungen zu erfüllen. Actions verfügen auch über eine integrierte Geheimnisverwaltung, mit der du sicher mit Drittanbieterdiensten interagieren und Bereitstellungsschlüssel sicher verwalten kannst.
Apps werden dauerhaft auf einem Server oder in einer Computeinfrastruktur ausgeführt, die du auf einem Benutzergerät bereitstellst oder ausführst. Sie können sowohl auf -Webhookereignisse als auch auf Ereignisse von außerhalb des -Ökosystems reagieren. Sie sind eine gute Option für Vorgänge, die mehrere Repositorys oder Organisationen umfassen, oder für die Bereitstellung gehosteter Dienste für andere Organisationen. Eine App ist die beste Wahl, wenn ein Tool mit Funktionen erstellt wird, die hauptsächlich außerhalb von verwendet werden oder mehr Ausführungszeit oder Berechtigungen benötigen, als für die Ausführung eines Actions-Workflows vorgesehen ist.
Weitere Informationen zum Vergleichen von Actions mit Apps findest du unter Informationen zu benutzerdefinierten Aktionen.
Du kannst eine App zum Authentifizieren in einem Actions-Workflow verwenden, wenn das integrierte _TOKEN nicht über ausreichende Berechtigungen verfügt. Weitere Informationen finden Sie unter Authentifizierte API-Anforderungen mit einer -App in einem Actions-Workflow.