Authentifizierung

Drei Anmeldeinformations-Familien werden an Kunden ausgegeben. Eine vierte existiert und ist intern. Sie wird hier aufgeführt, damit Sie nicht danach suchen müssen.

1. OAuth 2.1 mit PKCE: der MCP-Weg

Der primäre Weg für einen KI-Client, einen Store zu erreichen. Es ist ein vollständiger Autorisierungsablauf, kein eingefügter Schlüssel:

1. Der Client entdeckt die Metadaten des Autorisierungsservers.
2. Der Benutzer landet auf dem Zustimmungsbildschirm unter /oauth/authorize und sieht genau, welche Scopes angefragt werden.
3. Der Client tauscht den Code aus, PKCE-gebunden.
4. Das Zugriffstoken ist auf eine einzelne storeId begrenzt und gehasht im Ruhezustand gespeichert.

Verwenden Sie dies, wann immer der Client verhandeln kann. Es ist der einzige Weg, bei dem der Benutzer die Scope-Liste sieht und genehmigt, und der einzige, bei dem Sie eine Gewährung später einschränken können.

Im OAuth-Modus wird das Konto des Bearers bei jedem Aufruf geprüft, nicht nur das Token. Ein lebendes Token eines gesperrten oder gelöschten Kontos funktioniert nicht mehr.

2. bst_mcp_ — der statische MCP-Bearer

Für eine Maschine, die den OAuth-Ablauf nicht ausführen kann: einen CI-Job, einen Lauf ohne Browser. Claude Code und Cursor lesen eine Konfigurationsdatei und melden sich trotzdem per OAuth an; der Schlüssel ist ihr Rückfall, nicht ihr Standard.

• Pro Store geprägt, aus den Shopify-Custom-App-Einstellungen.
• Als SHA-256-Hash gespeichert; der Klartext wird nur einmal angezeigt und ist nie ableitbar.
• Den Schlüssel zu besitzen ist die Autorisierung. Er ist auf den Store begrenzt, also gibt es keine separate Scope-Verhandlung.

Die Konsequenz dieses letzten Punkts ist das, was zu verstehen ist: ein statischer Schlüssel erfüllt die Relay-Tool-Familie, die Tools, die Shopify über die Brücke erreichen. Er erfüllt nicht Tools, die eine BoostEcom-Ressource schützen, deren Berechtigung von einer Organisationsmitgliedschaft abhängt, weil es im statischen Modus keinen identifizierten Benutzer zum Prüfen gibt, und eine nicht prüfbare Berechtigung muss ablehnen statt durchlassen. Siehe MCP-Tools & Scopes.

3. bei_ — der Intelligence-Schlüssel

Ein nur lesendes Token für die Intelligence API.

• Trägt den Scope read:intelligence, der jetzt durchgesetzt wird, nicht nur gespeichert.
• Die Ratenobergrenze wird pro Schlüssel gezählt, nicht pro IP-Adresse.
• Als SHA-256-Hash gespeichert.

Alles außer einem reinen Bearer bei_<hex> wird rundweg abgelehnt, statt auf anonym herabgestuft zu werden.

Siehe Intelligence API.

4. bst_ — intern

Von Admins geprägte Tokens mit roadmap.*-Berechtigungen, verbraucht von einem internen Roadmap-MCP-Server. Wird nicht an Kunden ausgegeben. Nur aufgeführt, damit ein bst_-Präfix in einem Änderungsprotokoll Sie nicht auf die Suche nach einem Schlüssel schickt, den Sie nicht bekommen können.

Abgeschafft: die sk_-Familie

Wenn Sie in einem alten Dokument einen Verweis auf sk_-Schlüssel oder einen REST-Kanal-Endpunkt finden, ist er verschwunden. Diese Schlüssel lebten in einer prozesslokalen Map, sodass keine Anfrage je eine Instanzgrenze überschritt und jede geschützte Route mit 401 antwortete. Die Familie und der Endpunkt /api/channels/api wurden entfernt statt repariert.

Wählen

| Sie bauen | Verwenden Sie | |---|---| | Einen MCP-Client, der OAuth kann | OAuth 2.1 PKCE | | Einen MCP-Client auf einer Maschine ohne Browser (CI, headless) | bst_mcp_ | | Ein nur lesendes Intelligence-Skript | bei_ |