AEONHOST / WISSEN

Discord-Bot mit passenden OAuth2-Scopes installieren

Wenn du einen Discord-Bot in einem Server einsetzen willst, ist Guild Install der passende Installationskontext. Dazu gehören der Scope bot und nur die Serverberechtigungen, die der vorhandene Bot wirklich braucht. Für Slash-Commands wird zusätzlich der Scope applications.commands benötigt; Discord fügt ihn automatisch hinzu, wenn du bot anforderst. Eine App, die ohne Bot-Konto arbeitet, kann applications.commands auch allein verwenden.

Aktualisiert am 07.10.2026

Wenn du einen Discord-Bot in einem Server einsetzen willst, ist Guild Install der passende Installationskontext. Dazu gehören der Scope bot und nur die Serverberechtigungen, die der vorhandene Bot wirklich braucht. Für Slash-Commands wird zusätzlich der Scope applications.commands benötigt; Discord fügt ihn automatisch hinzu, wenn du bot anforderst. Eine App, die ohne Bot-Konto arbeitet, kann applications.commands auch allein verwenden.

Guild Install oder User Install?

Die Installationsart bestimmt, wo eine App installiert wird. GUILD_INSTALL installiert sie in einen Server. Wähle diesen Weg, wenn der Bot als Bot-Konto in einem Server mitarbeiten soll, etwa für Rollen, Moderation oder Serverereignisse. Der Scope bot fügt das Bot-Konto dem ausgewählten Server hinzu.

USER_INSTALL installiert die App für eine Person. Sie ist dadurch nur für die autorisierende Person sichtbar, kann aber – abhängig von den aktivierten Installations- und Befehlskontexten – in deren Servern, DMs und Gruppen-DMs verfügbar sein. Eine User-Installation fügt kein Bot-Konto zu einem Server hinzu und gewährt der App keine serverbezogenen Bot-Rechte. Die App muss sich an die Berechtigungen der Person auf der jeweiligen Oberfläche halten. Zusätzliche Zugriffe auf Kontodaten erfordern eigene OAuth2-Scopes. Discord bezeichnet die Kontexte in der Autorisierung als integration_type=0 für GUILD_INSTALL und integration_type=1 für USER_INSTALL. Die Anwendung muss den ausgewählten Kontext im Developer Portal unterstützen. Discord beschreibt die OAuth2-Kontexte und Scopes und führt die Installationskontexte und ihre Reichweite separat auf.

Bei globalen Commands sind Installationskontext und Befehlsoberfläche ebenfalls zwei verschiedene Einstellungen: integration_types legt fest, bei welcher Installationsart ein Command verfügbar ist. contexts bestimmt, wo im Discord-Client die Person ihn ausführen kann. Diese Felder gelten für globale Commands; ein Guild-Command ist an den Server gebunden, für den er registriert wurde. Eine User-Installation macht einen Command deshalb nicht automatisch in jedem Kontext sichtbar. Die Application-Commands-Dokumentation erklärt beide Felder.

Scopes und Serverrechte auseinanderhalten

OAuth2-Scopes beschreiben, welchen Zugriff die App anfordert. Die wichtigsten Fälle für einen vorhandenen Bot sind:

  • bot fügt ein Bot-Konto zu einem Server hinzu. Discord schliesst applications.commands dabei standardmässig ein.
  • applications.commands erlaubt der App, Befehle anzubieten. Der Scope kann unabhängig von bot verwendet werden; für diesen Befehls-Scope allein ist laut Discord kein Token-Austausch nötig.
  • identify, guilds und ähnliche Scopes betreffen zusätzliche Daten oder Aktionen eines Discord-Kontos. Nimm sie nur auf, wenn eine vorhandene Funktion diese Daten tatsächlich benötigt.
  • applications.commands.update ist für das Aktualisieren von Befehlen mit einem Bearer-Token aus dem Client-Credentials-Ablauf gedacht. applications.commands.permissions.update erlaubt das Ändern einzelner Befehlsrechte in einem Server, wenn die autorisierende Person dort die nötigen Rechte hat. Keiner der beiden Scopes ist eine zusätzliche Pflicht für eine gewöhnliche Bot-Einladung.

Der Parameter permissions ist kein OAuth2-Scope. Er fordert Serverrechte für das Bot-Konto an. Leite sie von den vorhandenen Bot-Funktionen ab: Ein Bot, der nur auf Befehle antwortet, braucht nicht automatisch Moderations-, Rollen- oder Administratorrechte. Administrator umgeht Kanalbeschränkungen und sollte nicht als pauschale Lösung für eine fehlende Einzelberechtigung dienen. Discord trennt Scopes und Bot-Autorisierung vom Server- und Kanalberechtigungsmodell.

Installation sicher prüfen

  1. Öffne die bestehende Anwendung im Discord Developer Portal. Prüfe, ob sie den benötigten Kontext GUILD_INSTALL oder USER_INSTALL unterstützt und welche Standard-Scopes und Rechte dafür hinterlegt sind. Ein Guild Install muss von einer Person mit MANAGE_GUILD autorisiert werden; für eine User-Installation braucht es keine serverbezogenen Bot-Rechte.
  2. Prüfe einen vorhandenen Autorisierungslink: Ohne explizite scope- oder integration_type-Angabe gelten die konfigurierten Standardwerte. Solche Parameter im Link können diese Werte überschreiben; gleiche deshalb Link und Portal-Einstellung ab.
  3. Verwende den Installationsweg für genau diesen Kontext. Für einen Server-Bot muss die Installation ein Bot-Konto hinzufügen; für eine reine App-Command-Installation kann applications.commands genügen.
  4. Lies im Discord-Bestätigungsdialog die angeforderte Serverberechtigung. Wenn dort Administrator oder eine Funktion auftaucht, die der Bot nicht braucht, stoppe und korrigiere die Installationskonfiguration.
  5. Prüfe nach der Installation das erwartete Ziel: Beim Guild Install sollte das Bot-Konto im ausgewählten Server erscheinen. Bei einer User-Installation muss der Befehl zu den aktivierten Installations- und Interaktionskontexten passen.

Ist die App bereits im richtigen Server, aber der Slash-Command fehlt, prüfe als Nächstes Registrierung und Sichtbarkeit nach der Anleitung zu fehlenden Discord-Slash-Commands. Geht es stattdessen um ein versehentlich offengelegtes Geheimnis, folge der Anleitung zum sicheren Verwalten des Bot-Tokens. Laufzeit, Startbefehl und Abhängigkeiten des bestehenden Projekts behandelt der Beitrag zum zuverlässigen Start eines Discord-Bots.

Diese Anleitung setzt eine bereits angelegte Discord-Anwendung und einen vorhandenen Bot oder eine vorhandene App-Funktion voraus. Sie erstellt keine OAuth2-URL und führt keine Anmeldung aus. Teile bei einer Supportfrage weder Bot-Token noch OAuth-Geheimnisse; eine Anwendungs-ID ist kein Ersatz für ein Token.