> ## Documentation Index > Fetch the complete documentation index at: https://docs.chatsailer.com/llms.txt > Use this file to discover all available pages before exploring further. # Autenticación > OAuth para una persona, un token de workspace para un script. Un servidor por grant. Cada petición MCP lleva una credencial bearer. No hay header de workspace — la credencial *es* el workspace. Dos tipos. Elige el que coincida con quién llama. | | OAuth | Token de workspace | | ---------------- | ------------------------------------------------ | ----------------------------------------------------- | | Para quién | Una persona en Claude, ChatGPT o Cursor | Un script, job de CI o Cloud Agent | | Cómo lo obtienes | Inicias sesión cuando el cliente abre un browser | Un admin emite `sk_live_…` en Sailer | | Quién hay detrás | La persona que aprobó | Nadie | | Visibilidad CRM | El ACL de esa persona | Todo el workspace | | Ligado a | Un servidor MCP | Ambos servidores, si los scopes del token lo permiten | `whoami` reporta `credential: oauth` o `credential: api_token`, y `reads_company_wide: true` cuando no hay usuario por el que filtrar. Pregúntalo cuando no estés seguro de qué tipo de conexión estás viendo. ## OAuth Esto es lo que recorren los [tutoriales de cliente](/es/mcp/connect). El cliente descubre el authorization server de Sailer, inicias sesión con tu email de Sailer, eliges un workspace si perteneces a más de uno, apruebas. Tres pantallas, en este orden: 1. **Auth0 sign-in** — el email que es miembro de un workspace de Sailer. ¿Ya estás con sesión iniciada? Este paso se salta. 2. **Consent** — qué workspace, y qué permisos. Un workspace por conexión, durante la vida del grant. Nada en una URL o en un argumento de tool puede cambiarlo. 3. **Done** — cierra la pestaña. El cliente ahora tiene tokens. Deja Client ID y Client Secret en blanco. Sailer registra el cliente él mismo. Pegar credenciales que inventaste, o de alguna otra app OAuth, es cómo esto falla. ### La primera conexión es solo lecturas El primer consent pide identity (`openid`, `profile`, `offline_access`) más cada scope `*:read` que tu rol realmente puede otorgar. Sin writes. Nadie debería aprobar "actualiza mi CRM" antes de haber leído un solo registro. Si le pides al modelo crear o actualizar algo, la tool va a decir que a la conexión le falta un scope y que **reintentar no va a ayudar**. Desconecta, vuelve a conectar y aprueba el write cuando el consent lo pida — contacts, organizations, deals o campaigns, lo que la tarea necesite. ### Los scopes son una intersección El consent muestra lo que *tu rol en ese workspace* puede otorgar. Los permisos tachados no son un bug — tu rol no puede cederlos. Pídele a un admin que amplíe el rol si los necesitas. Un scope es `:`. Las tools que no puedes llamar no aparecen en `tools/list`. Una conexión de solo lectura no debería ver `create_record` para nada. ### Un servidor por grant Un token OAuth se emite para exactamente un resource: `/mcp/crm` o `/mcp/studio`. Usar un token de CRM en Studio es **401**, no 403. Un desajuste de audience no es un scope faltante. Vuelve a conectar al otro servidor; no reintentes. ## Tokens de workspace Un token estático `sk_live_…` / `sk_test_…` es el camino de máquina. El mismo formato que la [API REST](/es/guides/authentication). Envíalo como `Authorization: Bearer sk_live_…`. No tiene usuario, así que el ACL de visibilidad del CRM no aplica: el token lee cada registro del workspace que sus scopes permitan. Trátalo como acceso a todo el workspace. Un token por integración, nunca en el control de versiones. ## Cambiar de workspace Una conexión está ligada a un workspace durante su vida. Para usar otro, quita el conector y agrégalo de nuevo, luego elige el otro workspace en el consent. La misma reconexión es cómo otorgas writes. No puedes apuntar una URL a dos workspaces a la vez.