Autenticazione

Tre famiglie di credenziali vengono rilasciate ai clienti. Ne esiste una quarta, interna. È elencata qui perché tu non debba cercarla.

1. OAuth 2.1 con PKCE: il percorso MCP

Il modo principale con cui un client IA raggiunge uno store. È un flusso di autorizzazione completo, non una chiave incollata:

1. Il client scopre i metadati del server di autorizzazione.
2. L'utente atterra sulla schermata di consenso su /oauth/authorize e vede esattamente quali scope vengono richiesti.
3. Il client scambia il codice, legato a PKCE.
4. Il token di accesso è delimitato a un singolo storeId e memorizzato con hash a riposo.

Usa questo ogni volta che il client sa negoziare. È l'unico percorso in cui l'utente vede e approva l'elenco degli scope, e l'unico in cui puoi poi restringere una concessione.

In modalità OAuth, l'account del bearer viene verificato a ogni chiamata, non solo il token. Un token vivo di un account bandito o eliminato smette di funzionare.

2. bst_mcp_ — il bearer MCP statico

Per una macchina che non può eseguire il flusso OAuth: un job di CI, un'esecuzione senza browser. Claude Code e Cursor leggono un file di configurazione e accedono comunque via OAuth; la chiave è il loro ripiego, non il loro default.

• Generato per store, dalle impostazioni della Custom App Shopify.
• Memorizzato come hash SHA-256; il testo in chiaro viene mostrato una sola volta e non è mai ri-derivabile.
• Possedere la chiave è l'autorizzazione. È delimitata allo store, quindi non c'è una negoziazione di scope separata.

La conseguenza di quest'ultimo punto è ciò che va capito: una chiave statica soddisfa la famiglia di strumenti relay, quelli che raggiungono Shopify tramite il ponte. Non soddisfa gli strumenti che proteggono una risorsa BoostEcom la cui autorizzazione dipende da un'appartenenza a un'organizzazione, perché in modalità statica non c'è un utente identificato da verificare, e un'autorizzazione non verificabile deve rifiutare piuttosto che lasciar passare. Vedi Strumenti e scope MCP.

3. bei_ — la chiave Intelligence

Un token di sola lettura per la Intelligence API.

• Porta lo scope read:intelligence, ora applicato, non solo memorizzato.
• Il tetto di frequenza è contato per chiave, non per indirizzo IP.
• Memorizzato come hash SHA-256.

Qualsiasi cosa diversa da un semplice Bearer bei_<hex> viene rifiutata direttamente invece di essere degradata ad anonimo.

Vedi Intelligence API.

4. bst_ — interno

Token generati da amministratori con permessi roadmap.*, consumati da un server MCP roadmap interno. Non rilasciato ai clienti. Elencato solo perché vedere un prefisso bst_ in un changelog non ti mandi a cercare una chiave che non puoi ottenere.

Ritirato: la famiglia sk_

Se trovi un riferimento a chiavi sk_ o a un endpoint di canale REST in un vecchio documento, è sparito. Quelle chiavi vivevano in una mappa locale al processo, quindi nessuna richiesta portava mai una di esse oltre un'istanza e ogni route protetta rispondeva 401. La famiglia e l'endpoint /api/channels/api sono stati rimossi invece che riparati.

Scegliere

| Stai costruendo | Usa | |---|---| | Un client MCP capace di fare OAuth | OAuth 2.1 PKCE | | Un client MCP su una macchina senza browser (CI, headless) | bst_mcp_ | | Uno script di intelligence in sola lettura | bei_ |