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:

  • Seguridad: es ampliamente conocido como un protocolo seguro.
  • Estandariación: es uno de los protocolos más extendidos del mercado y presenta estándares de comunicación.
  • Compatibilidad con MTLS: es decir, se pueden combinar ambas tecnologías.
  • Servicios externos que facilitan la implementación (ej: Auth0, Google Cloud, AWS, etc.)

Consideraciones generales:
  • El carrier debe disponibilizar de un endpoint que permita obtener un token para cada recurso expuesto (audience).
  • El endpoint disponibilizado debe ser del tipo POST ya que se trata de la creación de un token OAuth.
  • Para validar el acceso a este endpoint, Mercado Libre debe contar con un client_id y un client_secret provisto previamente por el carrier de forma segura.
  • El client_id y el client_secret serán enviados como parte del header Authentication del tipo Basic.
  • En el body del request no contendrá información del client_id ni del client_secret ya que se encuentran en el header.
  • En el body del request estará identificado el recurso al cual se solicita conceder acceso en el campo denominado audiencey el campo grant_type con el valor client_credentials, ya que de esta forma se identifica el flujo de integración entre sistemas.

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:

NombreDescripciónValor
Content-Typeapplication/jsonIndica el modo de alinear los sistemas de parsing
AuthorizationBasic <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:

NombreTipo de datoDescripciónTipo
audienceStringNombre del recurso sobre el que vamos a solicitar el token. Puede ser alguno de los valores siguientes:
  • authorizations
  • tracking-pull
  • agencies
  • booking
  • logistic-feed
  • handling-unit
  • rtt
  • fiscal-info
  • revoke
  • coverage
Mandatorio
grant_typeStringIdentificado el recurso al cual se solicita conceder accesoMandatorio

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:

NombreTipo de datoDescripciónTipo
access_tokenStringEl 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éricosMandatorio
token_typeStringIndica el tipo de token, siempre el tipo “Bearer” dado que se utiliza el flujo de client credentials.Mandatorio
expires_inLongTiempo de expiración del token expresado en segundos.Mandatorio

Status Codes

StatusCódigo HTTPDescripción
AUTHORIZED200Cuando la solicitud del token es resuelta de forma satisfactoria.
BAD REQUEST400Si no se incluye request body o está incompleto.
UNAUTHORIZED401Si las credenciales en el header Authorization Basic (client_id y client_secret) son incorrectas o no tienen acceso.
ERROR500Cualquier 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.

EndpointHeadersBodyResponse
POST https://service_url/oauth/revoke
  • Authorization: Bearer NEW_ACCESS_TOKEN_WITH_REVOKE_AUDIENCE
  • Content-Type: application/x-www-form-urlencoded
  • Content-Type: application/json

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.