GitHub-Apps vs. OAuth-Apps: Die richtige GitHub-Verbindung wählen
Vergleiche GitHub-Apps und OAuth-Apps für die Integration mit Logto. Erfahre die wichtigsten Unterschiede hinsichtlich Sicherheit, Berechtigungen, Token-Management und finde die passende GitHub-Authentifizierungsmethode für deine Anwendung.
Wenn du die GitHub-Authentifizierung in deine Logto-Anwendung integrierst, hast du zwei Möglichkeiten: GitHub-Apps und GitHub-OAuth-Apps. Beide ermöglichen die Funktion "Mit GitHub anmelden", bieten jedoch grundlegend unterschiedliche Erfahrungen bezüglich Sicherheit, Token-Management und API-Zugriff. Dieser Leitfaden hilft dir, die wichtigsten Unterschiede zu verstehen und den richtigen Ansatz für deinen Anwendungsfall zu wählen.
Hintergrund: Zwei Wege zur GitHub-Integration
Die aktuelle Logto-Dokumentation führt dich durch die Einrichtung einer GitHub OAuth App für Social Sign-in. Das ist die einfachere und unkompliziertere Option, die sich hervorragend für grundlegende Authentifizierungsanforderungen eignet. GitHub-Apps stellen jedoch den modernen, von GitHub selbst empfohlenen Ansatz dar und bieten erweiterte Sicherheitsfunktionen sowie eine granularere Steuerung.
Vergleiche es so: OAuth-Apps sind wie ein Generalschlüssel für dein Haus – sie erhalten nach der Autorisierung umfassenden Zugriff. GitHub-Apps hingegen sind wie ein intelligentes Schlosssystem mit spezifischen Zugangscodes für verschiedene Räume – die Nutzer können deinem App genau die Berechtigungen gewähren, die sie benötigt.
Die wichtigsten Unterschiede im Überblick
Berechtigungen: Breit vs. fein abgestuft
- OAuth-Apps verwenden breite Scopes – das Anfordern von
repogewährt vollständigen Repository-Zugriff. - GitHub-Apps verwenden fein abgestufte Berechtigungen – du kannst z. B. nur "Issues: Lesen" anfordern, ohne auf den Code zuzugreifen. Nutzer können außerdem bei der Installation spezifische Repositories auswählen, anstatt pauschalen Zugriff zu gewähren.
Token-Sicherheit: Permanent vs. ablaufend
- OAuth-Apps geben Tokens aus, die nie ablaufen (bis sie manuell widerrufen werden), ohne Mechanismus zum Aktualisieren.
- GitHub-Apps verwenden kurzlebige Tokens (1 Stunde Gültigkeit) mit automatischer Aktualisierung – deutlich sicherer für Anwendungen, die dauerhaft laufen.
Identität: Nutzer vs. Bot
- OAuth-Apps agieren immer als autorisierender Nutzer (z. B.
@octocat) und teilen deren Rate-Limit (5.000 Anfragen/Stunde). - GitHub-Apps können eigenständig mit einer eigenen Bot-Identität (z. B.
@my-app[bot]) agieren und erhalten skalierbare Rate-Limits, die mit der Nutzung steigen – ideal für Automatisierungen.
Zugriffskontrolle: Alles-oder-nichts vs. selektiv
- OAuth-Apps erfordern eine einmalige Autorisierung für alle erreichbaren Ressourcen.
- GitHub-Apps erlauben es den Nutzern, die App zu installieren, spezifische Repositories auszuwählen und erhalten Webhook-Benachrichtigungen über Berechtigungsänderungen – dies sorgt für mehr Transparenz und Kontrolle.
Persistenz: Nutzerabhängig vs. unabhängig
- OAuth-Apps sind an den autorisierenden Nutzer gebunden – verliert dieser Zugang oder verlässt das Unternehmen, funktioniert die App nicht mehr.
- GitHub-Apps funktionieren weiter, selbst wenn der Entwickler, der die App installiert hat, deine Organisation verlässt – das sichert unterbrechungsfreie Automatisierung und Integrationen.
Welche Option solltest du wählen?
Sowohl GitHub-Apps als auch OAuth-Apps funktionieren reibungslos mit dem Social Connector von Logto. Logtos Secret Vault speichert Tokens aus beiden Integrationen sicher, aber jede bietet eine andere Erfahrung:
Einfaches Social Sign-in mit OAuth-Apps
Wenn du nur Nutzer authentifizieren möchtest (Mit GitHub anmelden) und später keine GitHub-APIs aufrufst, ist der Weg über eine OAuth-App am schnellsten:
- Einfache Einrichtung: Die Nutzer autorisieren deine OAuth-App und melden sich via GitHub an.
- Tokens sind langlebig (kein Refresh): Logto kann das Zugangstoken in Secret Vault speichern, aber es gibt keinen Refresh-Flow – Tokens bleiben gültig, bis sie widerrufen werden.
- Am besten geeignet, wenn du nur Benutzeridentität (E-Mail, Name, Avatar) brauchst und keine automatisierten API-Aufrufe planst.
Warum diese Option wählen: Am schnellsten umgesetzt für Prototypen oder Apps, die lediglich Login oder gelegentlichen Profil-Sync benötigen.
Verbesserte Integration mit GitHub-Apps
Wähle eine GitHub-App, wenn deine Anwendung laufenden Zugriff auf GitHub-APIs, Hintergrundautomatisierung oder höhere Sicherheit benötigt:
- Fein abgestufte Berechtigungen und die Auswahl der Repositories pro Installation halten den Zugriff minimal und leichter prüfbar.
- Tokens sind kurzlebig (in der Regel 1 Stunde) und GitHub-Apps können Refresh-Tokens bereitstellen; sofern aktiviert, speichert Logto sowohl Zugangs- als auch Refresh-Tokens im Secret Vault und übernimmt das Rotieren, sodass dein Backend ohne erneuten Login weiter funktioniert.
- App-Identität (Bot) optimiert die Zuordnung und skalierbare Rate-Limits machen schwere Automatisierung zuverlässiger.
Am besten geeignet für:
- SaaS-Plattformen, die GitHub-Repositories im Namen ihrer Nutzer verwalten
- KI-Agenten, die mit Code, Issues oder Pull Requests interagieren
- Anwendungen, die dauerhaften API-Zugang brauchen
- Tools für Hintergrundautomatisierungsaufgaben
GitHub-App mit Logto einrichten
Die Einrichtung einer GitHub-App erfolgt ähnlich wie bei einer OAuth-App, mit ein paar wichtigen Unterschieden. Die Migration von einer OAuth-App zu einer GitHub-App benötigt nur geringen Aufwand.
GitHub-App erstellen
-
Navigiere zu "GitHub-Einstellungen > Entwicklungseinstellungen > GitHub-Apps"
-
Klicke auf "Neue GitHub-App"
-
Konfiguriere:
- Name der GitHub-App: Der eindeutige Bezeichner deiner App
- Homepage-URL: Deine Anwendungswebsite
- Callback-URL: Die Callback-URI deines Logto-Connectors (wie bei der OAuth-App)
- Nutzer-Autorisierung (OAuth) während der Installation anfordern: Aktivieren
- Webhook: Optional, je nach Bedarf
- Berechtigungen: Wähle fein abgestufte Berechtigungen (z. B. "Issues: Lesen")
- Nutzerberechtigungen: Füge Kontoberechtigungen hinzu, wenn die App im Namen der Nutzer agiert
-
Generiere ein Client-Secret (wie bei der OAuth-App)

Konfiguration in Logto
Die Konfiguration des Logto-Connectors ist nahezu identisch:
- Gib die Client-ID deiner GitHub-App ein
- Füge das Client-Secret hinzu
- Aktiviere „Tokens für dauerhaften API-Zugriff speichern“, falls du GitHub-APIs aufrufen musst
- Wichtiger Unterschied – Scopes:
- Im Unterschied zu OAuth-Apps (bei denen du Scopes in Logtos Scope-Feld eintragen musst), werden Berechtigungen bei der GitHub-App in deren Einstellungen festgelegt.
- Lasse das Scope-Feld in Logto einfach leer
- Refresh-Token anfordern (optional)
- Füge
offline_accessin das Scope-Feld in Logto ein, um Refresh-Tokens zu aktivieren - GitHub stellt dann automatisch ein Refresh-Token bereit, und Logto übernimmt Rotation und Speicherung beider Tokens im Secret Vault
- Hinweis: OAuth-Apps unterstützen keine Refresh-Tokens – ihre Zugangstokens laufen nie ab, daher ist
offline_accessnicht relevant. Das ist ein wesentlicher Unterschied bei der Integration mit GitHub-Apps.
- Füge

Fazit
OAuth-Apps sind weiterhin eine gute Wahl für einfache Authentifizierung, aber GitHub-Apps sind die Zukunft der GitHub-Integration. Sie bieten bessere Sicherheit durch ablaufende Tokens, ein präziseres Berechtigungsmodell und mehr Kontrolle für die Nutzer.
Für Logto-Nutzer funktionieren beide Optionen mit dem Social Connector. Die Auswahl hängt von deinen individuellen Anforderungen ab:
- Starte einfach mit OAuth-Apps, wenn du nur Authentifizierung brauchst
- Steige auf GitHub-Apps um, sobald du API-Zugriff, Automatisierung oder mehr Sicherheit benötigst
Und denk daran – Logtos Secret Vault und die automatische Token-Aktualisierung machen das Management von GitHub-App-Tokens genauso einfach wie bei OAuth-Apps, aber mit höherer Sicherheit. Egal, ob du einen KI-Coding-Assistenten, eine Projektmanagement-Plattform oder ein Entwickler-Tool baust: Jetzt kennst du die beste GitHub-Integration für deine Logto-Anwendung.
Bereit loszulegen? Schau dir den Logto-GitHub-Connector an und starte heute mit der GitHub-Authentifizierung.

