Autenticación y Autorización
Contenidos
→Enviar access token por header
→Autenticación
→Autorización
→Server side
↳Paso a paso
↳Parámetros
→Refresh token
↳Parámetros
→Referencia de códigos de error
↳Error Invalid Grant
Enviar access token por header
Conoce más sobre la seguridad de tu desarrollo.
Autenticación
El proceso de autenticación es utilizado para verificar la identidad de una persona en función de uno o varios factores, asegurando que los datos de quien los envió sean los correctos. Si bien existen diferentes métodos, en Mercado Libre utilizamos el basado en contraseñas. Los pasos a seguir son:
- Autenticate con tu usuario de Mercado Libre:
- Coloca la siguiente URL en la ventana de tu navegador para obtener la autorización:
- Como último paso, el usuario será redirigido a la siguiente pantalla donde se le solicitará que vincule la aplicación con su cuenta.

http://auth.mercadolibre.com.ar/authorization?response_type=code&client_id=$APP_ID&redirect_uri=$YOUR_URL
Ejemplo:
Si cuando se creó la app se hizo con Redirect URI:

Es necesario que el llamado al recurso /authorization sea de la siguiente forma:
http://auth.mercadolibre.com.ar/authorization?response_type=code&client_id=$APP_ID&redirect_uri=https://mercadolibre.com.ar


Si revisamos la URL, se puede observar que se agregó el parámetro code.
http://YOUR_REDIRECT_URI?code=$SERVER_GENERATED_AUTHORIZATION_CODE
Este code, será utilizado cuando se necesite generar un access token, que permitirá el acceso a nuestras API.
Autorización
La autorización es el proceso por el cual permitimos acceder a recursos privados. En este proceso, se deberá definir qué recursos y operaciones se pueden realizar (“sólo lectura” o “lectura y escritura”).
¿Cómo logramos la autorización?
A través del Protocolo OAuth 2.0, uno de los más utilizados en plataforma abiertas (Twitter, Facebook, etc.) y método seguro para trabajar con recursos privados.
Este protocolo nos brinda:
- Confidencialidad, el usuario no deberá revelar su clave en ningún momento.
- Integridad, solo podrán ver datos privados aquellas aplicaciones que tengan el permiso de hacerlo.
- Disponibilidad, los datos siempre estarán disponibles en el momento que se necesiten.
Dentro de este protocolo existen 4 modos de funcionamiento posibles denominados Grant Types:
- The Authorization Code Grant Type (Server Side)
- The Implicit Grant Type (Client Side)
- The Password Credentials Grant Type
- The Client Credentials Grant Type
A continuación te mostraremos cómo trabajar con los recursos de Mercado Libre utilizando el flujo Authorization Code en el Server Side.
Server side
El flujo Server side es el más adecuado para las aplicaciones que ejecutan código del lado del servidor. Por ejemplo, aplicaciones desarrolladas en lenguajes como Java, Grails, Go, etc.
Nosotros te recomendamos que utilices nuestros SDKs ya que te facilitarán la complejidad del flujo de autorización utilizando el protocolo OAuth.
En resumen, el proceso que estarás realizando es el siguiente:

Referencias
- Redirecciona la aplicación a Mercado Libre
- No tienes que preocuparte por la autenticación de los usuarios a Mercado Libre, ¡nuestra plataforma se encargará de ello!
- Página de autorización
- POST para intercambiar el código de autorización por un access token
- La API de Mercado Libre intercambia el código de autorización por un access token
- Ya puedes utilizar el access token para realizar llamadas a nuestra API y así obtener acceso a los datos privados del usuario
Paso a paso
- Al iniciar el flujo de autorización, la aplicación que desarrolles deberá redireccionar a Mercado Libre para que los usuarios puedan autenticarse y posteriormente autorizar tu aplicación. En el navegador ingresa la siguiente dirección:
- Una vez que el usuario inicie sesión será redireccionado a la página de autorización de la aplicación. Allí se le presentarán todos los permisos solicitados.
Otorgados los permisos el usuario será redireccionado al REDIRECT URI configurado en la aplicación con el access token correspondiente: - El código de autorización es utilizado para intercambiarlo por un access token.
https://auth.mercadolibre.com.ar/authorization?response_type=code&client_id=$APP_ID&redirect_uri=$YOUR_URL
Parámetros
Response_type: enviando el valor “code” se obtendrá un access token que le permitirá a la aplicación interactuar con Mercado Libre.
Client_id: es el APP ID de la aplicación que se creó.
Para mayor seguridad, te recomendamos incluir el parámetro state en la URL de autorización para asegurarte que la respuesta pertenece a una solicitud iniciada por tu aplicación.
En caso de no tener un identificador aleatorio seguro, puedes crearlo utilizando SecureRandom y deberá ser único por cada intento de llamada (request).
Por ende, la URL de redirección será:
https://auth.mercadolibre.com.ar/authorization?response_type=code&client_id=$APP_ID&state=$RANDOM_ID&redirect_uri=$REDIRECT_URL
Ejemplo:
https://auth.mercadolibre.com.ar/authorization?response_type=code&client_id=$APP_ID&state=ABC1234&redirect_uri=$REDIRECT_URL
http://YOUR_REDIRECT_URI?code=SERVER_GENERATED_AUTHORIZATION_CODE
Si en el paso anterior habías incorporado el parámetro state, recibirás el código de autorización y también el identificador seguro en la URL de retorno especificada:
http://YOUR_REDIRECT_URI?code=$SERVER_GENERATED_AUTHORIZATION_CODE&state=$RANDOM_ID
Ejemplo:
http://YOUR_REDIRECT_URI?code=$SERVER_GENERATED_AUTHORIZATION_CODE&state=ABC1234
Recuerda chequear ese valor para asegurarte que la respuesta pertenece a una solicitud iniciada por tu aplicación.
Desde Mercado Libre no validamos este campo.
Debes realizar un POST enviando los parámetros por BODY:
curl -X POST \
-H 'accept: application/json' \
-H 'content-type: application/x-www-form-urlencoded' \
'https://api.mercadolibre.com/oauth/token' \
-d 'grant_type=authorization_code' \
-d 'client_id=$APP_ID' \
-d 'client_secret=$SECRET_KEY' \
-d 'code=$SERVER_GENERATED_AUTHORIZATION_CODE' \
-d 'redirect_uri=$REDIRECT_URI'
Respuesta:
{
"access_token": "APP_USR-123456-090515-8cc4448aac10d5105474e1351-1234567",
"token_type": "bearer",
"expires_in": 10800,
"scope": "offline_access read write",
"user_id":1234567,
"refresh_token": "TG-5b9032b4e23464aed1f959f-1234567"
}
Parámetros
grant_type: authorization_code indica que la operación deseada es intercambiar el “code” por un access token.
client_id: es el APP ID de la aplicación que se creó.
client_secret: es Secret Key que se generó al crear la aplicación.
code: el código de autorización obtenido en el paso anterior.
redirect_uri: el redirect URI configurado para tu aplicación o uno de los dominios permitidos.
¡Listo! Ya puedes utilizar el access token para realizar llamadas a nuestra API y así obtener acceso a los recursos privados del usuario.
Refresh token
Ten en cuenta que el access token generado expirará transcurridas 6 horas desde que se solicitó. Por eso, para asegurar que puedas trabajar por un tiempo prolongado y no sea necesario solicitar constantemente al usuario que se vuelva a loguear para generar un token nuevo, te brindamos la solución de trabajar con un refresh token.
Cada vez que realices la llamada que intercambie el code por un access token, también vendrá el dato de un refresh_token, que deberás guardar para intercambiarlo por un nuevo access token una vez que expire.
Para renovar tu access token debes efectuar la siguiente llamada:
curl -X POST \
-H 'accept: application/json' \
-H 'content-type: application/x-www-form-urlencoded' \
'https://api.mercadolibre.com/oauth/token' \
-d 'grant_type=refresh_token' \
-d 'client_id=$APP_ID' \
-d 'client_secret=$SECRET_KEY' \
-d 'refresh_token=$REFRESH_TOKEN'
Parámetros
grant_type: refresh_token indica que la operación deseada es actualizar un token.
refresh_token: el refresh token del paso de aprobación guardado previamente.
client_id: es el APP ID de la aplicación que se creó.
client_secret: es Secret Key que se generó al crear la aplicación.
Respuesta:
{
"access_token": "APP_USR-12345657984-090515-b0ad156bce70050973466faa15-1234567",
"token_type": "bearer",
"expires_in": 10800,
"scope": "offline_access read write",
"user_id":1234567,
"refresh_token": "TG-5b9032b4e4b0714aed1f959f-1234567"
}
La respuesta incluye un nuevo access token válido por 6 horas más y un nuevo REFRESH_TOKEN que necesitarás guardar para utilizarlo cada vez que expire.
Referencia de códigos de error
invalid_client: el client_id y/o client_secret de tu aplicación provisto es inválido.
invalid_grant: este error se puede producir por diferentes motivos relacionados con el authorization_code y refresh_token, puede ser porque el authorization_code o refresh_token son inválidos, fueron revocados o expiraron, se envió en el flujo incorrecto, pertenece a otro cliente o si el redirect_uri usado en el flujo de autorización no coinciden con el configurado en su aplicación.
invalid_scope: el alcance solicitado es inválido, desconocido o está mal formado. Los valores permitidos para el parámetro alcance son: “offline_access”,”write”,”read”.
invalid_request: la solicitud no incluye un parámetro obligatorio, incluye un parámetro o valor de parámetro no soportado, hay algún valor duplicado o está mal formada de otro modo.
unsupported_grant_type: los valores permitidos para grant_type son “authorization_code” o “refresh_token”.
forbidden: la llamada no autoriza el acceso, posiblemente se está utilizando el token de otro usuario.
unauthorized_client: la aplicación no tiene autorización para el usuario solicitado o la autorización existente no autoriza los scopes con los que se quiere crear el token.
Error Invalid Grant
En el flujo de refresh token o authorization code es posible obtener el error invalid_grant con el mensaje "Error validating grant. Your authorization code or refresh token may be expired or it was already used"
{
"message": "Error validating grant. Your authorization code or refresh token may be expired or it was already used",
"error": "invalid_grant",
"status": 400,
"cause": []
}
El mensaje indica que el authorization_code o refresh_token enviados no existen y los mismos fueron borrados. Algunos de los motivos son:
- Expiración: cumplido el tiempo de duración del refresh_token (6 meses), expira automáticamente y se debe realizar nuevamente el proceso para obtener uno nuevo.
- Revocación de autorización: al revocarse la autorización entre seller y aplicación (ya sea por parte del integrador o el seller), se dispara el borrado de todos los access_token y refresh_token asociados a los mismos. Puedes verificar aquellos sellers que ya no tienen grant con tu aplicación, desde la opción “Administrar Permisos” (en el panel de Mis Aplicaciones) o utilizando el recurso para acceder al listado de usuarios que otorgaron permiso a tu aplicación.
- Revocación Interna: existen algunos flujos internos que realizan borrado de credenciales de los usuarios, lo cual impide que los integradores puedan seguir actuando en nombre del seller, y tengan que realizar nuevamente el flujo de autorización/autenticación. Estos flujos son disparados principalmente por borrado de sesión de usuario; los motivos son varios, destacándose como los más comunes el cambio de contraseña, desvinculación de dispositivos o detección de fraude.
Siguiente: Consulta usuarios.