OAuth Token
Contenidos
Se plantea el uso de la autenticación del cliente vía OAuth 2.0 sobre TLS como alternativa a Mutual TLS para cada integración, pudiendo contar con un token diferente para cada recurso del carrier.
El uso de esta alternativa está sustentado en:
Un ejemplo de comunicación:

Formato Request
El request tendrá el siguiente formato
POST {url}/oauth/token--header 'Content-Type: application/json'--header 'Authorization: Basic <Base64 encoded $client_id:$client_secret>'--data-raw '{"audience": "<API_IDENTIFIER>","grant_type": "client_credentials"}'
Se enviarán los headers listados a continuación:
| Nombre | Descripción | Valor |
|---|---|---|
| Content-Type | application/json | Indica el modo de alinear los sistemas de parsing |
| Authorization | Basic <Base64 encoded $client_id:$client_secret> | Es del tipo Basic. Incluye el client_id y el client_secret unidos por dos puntos (:) y codificado en Base64. Se codifica en Base64 para evitar problemas con caracteres que no sean soportados para transmitirse por HTTP. |
Dentro del body se enviará un objeto JSON con los campos listados a continuación:
| Nombre | Tipo de dato | Descripción | Tipo |
|---|---|---|---|
| audience | String | Nombre del recurso sobre el que vamos a solicitar el token. Puede ser alguno de los valores siguientes:
| Mandatorio |
| grant_type | String | Identificado el recurso al cual se solicita conceder acceso | Mandatorio |
Formato Response
El response deberá tener el siguiente formato
HTTP 200 OK--header 'Content-Type: application/json'{"access_token": "<ACCESS_TOKEN>","token_type": "Bearer","expires_in": 86400}
Dentro del body, el sistema devolverá todos los datos resultantes listados a continuación:
| Nombre | Tipo de dato | Descripción | Tipo |
|---|---|---|---|
| access_token | String | El token de acceso a ser incluido en las llamadas al recurso externo para su validación. Es una cadena ofuscada, que no pretende tener ningún significado para los clientes que la usan. Se permiten caracteres alfanuméricos | Mandatorio |
| token_type | String | Indica el tipo de token, siempre el tipo “Bearer” dado que se utiliza el flujo de client credentials. | Mandatorio |
| expires_in | Long | Tiempo de expiración del token expresado en segundos. | Mandatorio |
Status Codes
| Status | Código HTTP | Descripción |
|---|---|---|
| AUTHORIZED | 200 | Cuando la solicitud del token es resuelta de forma satisfactoria. |
| BAD REQUEST | 400 | Si no se incluye request body o está incompleto. |
| UNAUTHORIZED | 401 | Si las credenciales en el header Authorization Basic (client_id y client_secret) son incorrectas o no tienen acceso. |
| ERROR | 500 | Cualquier error del lado del servidor como caídas de servicio. |
Revocación de Token OAuth
La revocación de tokens de OAuth en MercadoLibre se asemeja al estándar de la IETF, el cual establece que, para la revocación de tokens generados a través del protocolo OAuth 2.0, el cliente puede notificar al servidor de autorización que un token de acceso específico ya no debe ser considerado como válido. Adicionalmente, esta característica nos va a permitir accionar bajo demanda ante alguna eventualidad que se presente, sin importar el tiempo de expiración del token es decir, no debemos esperar que el token expire su vigencia. La request de revocación de un token se realiza mediante una petición HTTP POST al endpoint de revocación. Dicha request debe incluir el token que se desea revocar. El formato del cuerpo de la request debe ser application/x-www-form-urlencoded y contener un parámetro ‘token’ con el valor del token a revocar. Como respuesta el servidor indica si el token fue revocado correctamente. Si fue exitosa, el servidor devuelve un código de estado HTTP 200. Si el token no pudo ser revocado, se devuelve un código de estado HTTP 4xx o 5xx. Como requisito de seguridad el estándar establece medidas para garantizar que solo el titular legítimo del token pueda revocar. Esto incluye la autenticación del cliente que realiza la solicitud de revocación. Utilizando un token de acceso válido generado por la audience “revoke” para la cual el proveedor logístico debe habilitar la generación de token.
Adicionalmente a la autenticación, el cliente debe tener los permisos adecuados para realizar la revocación del token (audience). Por ejemplo, un token solo puede ser revocado por el mismo cliente y con la audiencia “revoke”. Nunca se deberá poder revocar un token si el token de la cabecera es el mismo al que se solicita revocar.

| Endpoint | Headers | Body | Response |
|---|---|---|---|
| POST https://service_url/oauth/revoke |
|
|
Request
curl -X POST https://service_url/oauth/revoke
-H 'Authorization: Bearer NEW_ACCESS_TOKEN_WITH_REVOKE_AUDIENCE'
-H 'Content-Type: application/x-www-form-urlencoded'
-d 'token=ACCESS_TOKEN_TO_REVOKE'
Formatos de response para Revocación de Token OAuth
2xx OK
{
"status": "OK"
}4XX FAILED
{
"status": "FAILED",
"message": "Mensaje descriptivo que indica el motivo de la falla"
}5XX ERROR
{
"status": "ERROR",
"message": "Mensaje descriptivo que indica el motivo del error en el servidor"
}Suite de Test
Hay una sección en la suite de test para simular la llamada al endpoint /oauth/token con un formulario para que los carriers puedan indicar los datos de client_id, client_secret y un dropdown para las diferentes audiencias (api identifiers). El docker se encarga de armar el header Authorization Basic con las credenciales codificadas en Base64 para incluir en el request. Para las pruebas del resto de las integraciones (Auth, Cancel, Agency Auth, Agency, Booking, Tracking Pull) se habilitará un campo para incluir un token de la api call simulada. El carrier debe ingresar el token ya generado y el docker se encarga de agregar el header Bearer con dicho token.