---
source: https://docs.restoman.com.ar/developers/oauth
language: es-AR
updated: 2026-11-02
---

# OAuth y permisos

> Cómo un agente obtiene acceso a un negocio con OAuth 2.1, qué permite cada permiso y cómo se revoca.

El acceso al [MCP de Restoman](https://docs.restoman.com.ar/developers/mcp.md) es OAuth 2.1 con PKCE. El servidor de autorización es `https://api.restoman.com.ar`; el recurso protegido, `https://api.restoman.com.ar/mcp`. El mismo flujo, paso a paso y para agentes, está en `https://api.restoman.com.ar/auth.md`.

## Descubrir

1. Una llamada al MCP sin token responde `401` con `WWW-Authenticate: Bearer resource_metadata="https://api.restoman.com.ar/.well-known/oauth-protected-resource/mcp"`.
2. Ese documento (RFC 9728) nombra el servidor de autorización y los permisos.
3. Los datos del servidor están en `https://api.restoman.com.ar/.well-known/oauth-authorization-server` (RFC 8414) y en `/.well-known/openid-configuration`.

## Registrarse

No hay claves para pedir. El agente se registra solo, de una de dos formas:

- **Client ID Metadata Document**, la forma que prefiere MCP: el `client_id` es una dirección https que sirve los datos del cliente.
- **Registro dinámico** (RFC 7591) en `https://api.restoman.com.ar/api/auth/oauth2/register`, sin autenticarse. Mandá `"token_endpoint_auth_method": "none"` para registrarte como cliente público; si no, el registro te da un secreto (`client_secret_basic`), que tenés que guardar y mandar.

Un cliente que no pide permisos recibe los de lectura y `offline_access`.

## Autorizar

1. Mandá a la persona a `https://api.restoman.com.ar/api/auth/oauth2/authorize` con `response_type=code`, tu `client_id` y `redirect_uri`, un `code_challenge` con `S256`, los permisos en `scope` y `resource=https://api.restoman.com.ar/mcp`.
2. La persona ingresa al panel de Restoman con el código que le llega por email.
3. Si es parte de más de un negocio, elige a cuál te conecta. Cada permiso es para un solo negocio.
4. Marca qué te deja hacer: lo que solo lee viene marcado; lo que cambia cosas, no.
5. Vuelve a tu `redirect_uri` con un `code`, que cambiás por los tokens en `https://api.restoman.com.ar/api/auth/oauth2/token`.

Pedí `offline_access` para recibir un token de refresco. Los tokens de acceso son JWT para ese recurso y ese negocio, duran 10 minutos, y el de refresco cambia en cada uso. Se aceptan tokens atados a DPoP.

El soporte de Restoman, mientras ve el panel como otra persona, no puede conectar agentes por ella.

## Permisos

| Permiso             | Qué permite                                   | Al conectar |
| ------------------- | --------------------------------------------- | ----------- |
| `menu:read`         | Leer las cartas y lo que está agotado         | marcado     |
| `orders:read`       | Leer los pedidos para llevar                  | marcado     |
| `reports:read`      | Leer las ventas                               | marcado     |
| `menu:availability` | Marcar platos agotados, o volver a ofrecerlos | sin marcar  |
| `orders:pause`      | Pausar y reanudar los pedidos para llevar     | sin marcar  |
| `menu:translate`    | Traducir los textos de la carta a otro idioma | sin marcar  |

Cada permiso es un techo sobre lo que el rol de la persona ya le deja hacer en ese negocio: con `reports:read`, un mozo igual no ve las ventas, y la herramienta responde por qué.

## Revocar

- **La persona te desconecta** en **Asistentes**, en el panel: el permiso termina al instante y la próxima llamada responde `401`.
- **Vos podés revocar un token de refresco** en `https://api.restoman.com.ar/api/auth/oauth2/revoke` (RFC 7009). Los tokens de acceso son JWT: no se revocan uno por uno (ese endpoint responde `unsupported_token_type`) y dejan de servir cuando vencen, en 10 minutos como mucho.