Autenticación
Cada llamada /osl/* lleva un token JWT Bearer. El motor autoriza contra los
scopes y roles del token, y el punto de aplicación de política aplica la ACL del
llamante server-side.
Authorization: Bearer <jwt>El token
Sección titulada «El token»El JWT lleva:
| Claim | Significado |
|---|---|
chain[] |
La cadena de delegación, raíz → hoja (el sujeto que actúa es el último eslabón) |
sub |
Opcional; si está presente, debe ser igual a chain[-1] |
roles[] |
Roles asignados |
tenant |
La celda del tenant |
scopes[] |
osl:read, osl:write, osl:execute, osl:admin |
exp |
Caducidad (obligatoria) |
La cadena de delegación
Sección titulada «La cadena de delegación»El acceso se evalúa sobre una cadena de sujetos (raíz → hoja), no sobre una única identidad — ver Acceso y capacidades. La cadena está dentro del payload firmado (HS256), de modo que un llamante no puede acortarla ni falsificarla sin romper la firma:
{ "iss": "opendome", "chain": ["ana@company.com", "agent://copilot-finance"], "roles": ["analyst"], "iat": 1750000000, "exp": 1750000300}De dónde vienen los tokens
Sección titulada «De dónde vienen los tokens»| Edición | Emisor |
|---|---|
| OSS standalone Apache-2.0 | La celda acuña tokens HS256 localmente. El chart de tenant-semantic-api genera un Secret de firma; usa scripts/osl-token.sh <tenant> --roles <r> para acuñar uno. El motor standalone no confía en la cabecera X-Actor-Roles — un llamante de un Ingress público no puede falsear roles. |
| Enterprise / managed Enterprise | El control-plane emite y rota los JWTs. También puedes anteponer al motor tu propio proxy con conciencia de IdP que ponga X-Actor-Roles y activar auth.trustActorRolesHeader=true (BYO-OIDC). |
Rate limits
Sección titulada «Rate limits»Valores por defecto, por sujeto:
| Endpoint | Límite |
|---|---|
POST /osl/query |
60 rps |
POST /osl/sample |
30 rps |
GET /osl/schema |
5 rps (cacheado) |
Excedido → 429 Too Many Requests con Retry-After. Los límites se configuran
por tenant en el tier managed.
Auditoría
Sección titulada «Auditoría»Cada petición — 200 o no — produce una entrada de auditoría inmutable y
encadenada por hash con request_id, sujeto, acción, los FQNs de los objetos
tocados, la decisión y un timestamp.