Saltar al contenido principal

Obtención de Access Tokens

DVS utiliza el grant_type OAuth2 client credentials para autenticación service-to-service. El OSIGU Auth Server usa HTTP Basic auth para identificar al cliente y query string para el grant_type — esta página muestra la forma exacta de la request e implementaciones listas para copiar y pegar en 5 lenguajes.

Endpoints

EntornoToken URL
Sandboxhttps://sandbox.osigu.com/v1/oauth/token
Producciónhttps://api.osigu.com/v1/oauth/token

Las credenciales están limitadas por entorno — el client_id de sandbox no funciona contra la token URL de producción.

Forma de la request

grant_typestringrequired

Enviado como parámetro de query string (no en el body). Siempre client_credentials.

Authorizationheaderrequired

HTTP Basic auth: Basic <base64(client_id:client_secret)>. Usar las credenciales emitidas por OSIGU para el entorno correspondiente.

Method: POST Body: vacío Content-Type: no requerido (sin body)

Response

{
"access_token": "7dd4f350-676e-4257-9d7b-f3c5ac4dfi14",
"token_type": "bearer",
"expires_in": 86399,
"scope": "read write",
"extensions": {
"provider_slug": "br-gamma"
}
}
CampoDescripción
access_tokenToken opaco (no un JWT). Enviarlo como Authorization: Bearer <token> en las llamadas subsecuentes a la API de DVS.
token_typeSiempre bearer.
expires_inSegundos hasta la expiración. Por defecto 86399 (~24 horas).
scopeScope OAuth2 grueso otorgado al token (p. ej., read write). Las authorities más finas por endpoint de DVS se aplican del lado del servidor a partir de la configuración del client_id.
extensionsMapa de metadatos de forma libre. Incluye el provider_slug (usarlo para registrar a qué tenant pertenece el token). Puede incluir otros campos por tenant que OSIGU agregue en el futuro.

Ejemplos de código

curl --location --request POST \
"https://sandbox.osigu.com/v1/oauth/token?grant_type=client_credentials" \
--header "Authorization: Basic $(echo -n "$DVS_CLIENT_ID:$DVS_CLIENT_SECRET" | base64)"

Buenas prácticas

Cachear los tokens

Los tokens son válidos por ~24 horas por defecto. Cachearlos en memoria (o en un caché compartido como Redis para servicios multi-instancia) y refrescarlos ~60 segundos antes de la expiración. Llamar al endpoint OAuth en cada request a la API resultará en rate limiting y latencia innecesaria.

Almacenar los secrets en un vault, no en archivos env

Usar AWS Secrets Manager, HashiCorp Vault, Doppler o equivalente. Rotar el client_secret anualmente (o tras cualquier sospecha de exposición) contactando a OSIGU.

Manejar 401 refrescando

Si una request devuelve 401, el token puede haber expirado o haber sido revocado. Descartar el token cacheado, solicitar uno nuevo y reintentar la request original una sola vez. No reintentar indefinidamente.

No loguear tokens

Eliminar los headers Authorization de los logs de la aplicación. Un token filtrado puede ser válido hasta 24 horas.

Usar extensions.provider_slug para observabilidad

Loguear el provider_slug de la response del token junto con los IDs de request. Esto acelera mucho la correlación de problemas con el soporte de OSIGU.

Errores

StatusBodyCausa
400error: "invalid_request"Falta el grant_type en el query string.
401error: "invalid_client"client_id o client_secret incorrectos, o entorno equivocado (credenciales de sandbox contra la URL de producción).
405Method Not AllowedSe usó GET en lugar de POST.
429rate limitedDemasiadas solicitudes de token. Cachear y reducir el ritmo.
5xxserver errorCaída del Auth Server. Reintentar con exponential backoff (máx. 3).