> ## Documentation Index
> Fetch the complete documentation index at: https://storekit.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Autenticazione

> Come un client si autentica al merchant MCP di storekit: OAuth 2.1 con discovery della protected-resource e sign-in dalla dashboard storekit.

Il merchant MCP si autentica con OAuth 2.1. Ogni chiamata a uno strumento è limitata all'account a cui il token si risolve; nulla negli argomenti di uno strumento può cambiare questo.

| | OAuth (sign-in) |
| - | - |
| Header | `Authorization: Bearer <token>` |
| Identità | Un utente della dashboard storekit |
| Account | Il primo account dell'utente |
| Requisiti | Un account nella waitlist della beta: [richiedi l'accesso](https://t09czsyu90l.typeform.com/to/G6rIJWNv) |

Una richiesta non autenticata riceve `401` con un header `WWW-Authenticate` (sotto).

## OAuth

L'endpoint è una protected resource OAuth 2.1. L'authorisation server è ospitato da [Scalekit](https://www.scalekit.com), con il login stesso delegato alla dashboard storekit, in modo che un utente acceda con le sue normali credenziali storekit.

**1. Discovery**

Una `POST /mcp` non autenticata restituisce:

```http theme={null}
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="OAuth", resource_metadata="https://mcp.storekit.com/.well-known/oauth-protected-resource"
```

Fai `GET` di quell'URL per ottenere i metadata della protected resource:

```json theme={null}
{
  "resource": "https://mcp.storekit.com",
  "authorization_servers": ["https://storekit.eu.scalekit.com/resources/res_143363546435027719"],
  "bearer_methods_supported": ["header"],
  "scopes_supported": ["read"]
}
```

I metadata dell'authorisation server stesso sono sul suo path `/.well-known/oauth-authorization-server`, come al solito. I client si registrano lì; non c'è alcun client ID o secret da configurare. I client che supportano lo standard MCP authorisation (Claude, ChatGPT, Cursor, VS Code, Claude Code) fanno tutto questo senza configurazione.

**2. Sign-in**

L'authorisation server reindirizza l'utente alla dashboard storekit, che mostra **Connecting your MCP client, please wait...** mentre conferma la richiesta di login con l'API storekit, e poi rimanda al client. Un utente che non è loggato nella dashboard accede prima. Se l'utente appartiene a più account, il token si risolve al suo **primo** account; non c'è un selettore di account.

**3. Chiamate**

Invia l'access token come `Authorization: Bearer`. Il `sub` del token è l'utente storekit; il suo claim `scope` viene allegato alla richiesta come `scopes` (default `read`). Rinnova come la tua libreria OAuth prevede; un token scaduto riceve un `401` e il client rifà la discovery.

> [!NOTE]
>
> I ruoli utente della dashboard e l'accesso per singolo locale non si applicano a MCP. Un token per un utente che può vedere un solo locale nella dashboard legge ogni locale dell'account, e può chiamare i due strumenti di scrittura. Scegli di conseguenza chi si collega, consulta [Autorizzazioni e privacy](/docs/it/guides/ai/permissions-and-privacy).

## Verifica dell'endpoint

Una chiamata non autenticata è sufficiente per confermare che il server è raggiungibile e per vedere l'header di discovery che un client segue:

```bash theme={null}
curl -si https://mcp.storekit.com/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
```

Aspettati `401 Unauthorized` con l'header `WWW-Authenticate` mostrato sopra. Per domande sull'accesso o sulla beta: [mcp@storekit.com](mailto:mcp@storekit.com).

## Verifiche di Origin e Host

Le richieste che portano un header `Origin` vengono verificate contro l'allow-list di storekit delle origin del browser quando ne è configurata una, e rifiutate con `403` prima dell'autenticazione se non corrispondono. Le richieste senza header `Origin` (ogni client desktop, CLI e server) passano direttamente all'autenticazione. L'header `Host` deve corrispondere all'hostname pubblico.

## Rate limit

60 richieste per minuto scorrevole, con chiave per utente (per IP prima dell'autenticazione). Superarlo restituisce HTTP `429` con un header `Retry-After`, al di fuori dell'envelope MCP.


## Related topics

- [Deliverability delle email](/docs/it/guides/notifications/email-deliverability.md)
- [Politica di sicurezza](/docs/it/privacy-security/security-policy.md)
- [TISSL](/docs/it/guides/integrations/pos/tissl.md)
- [Zonal (Aztec)](/docs/it/guides/integrations/pos/zonal.md)
- [Errori](/docs/it/developers/mcp/errors.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.