Autenticación y Autorización

Para comenzar a utilizar nuestros recursos es necesario que puedas desarrollar los procesos de Autenticación y Autorización. De esta manera, podrás trabajar con los recursos privados del usuario cuando autorice tu aplicació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

Por seguridad, debes enviar el access token por header cada vez que realices llamadas a la API. 
Authorization: Bearer APP_USR-12345678-031820-X-12345678
Y por ejemplo, realizando un GET al recurso /users/me sería: 
curl -H ‘Authorization: Bearer APP_USR-12345678-031820-X-12345678’ \
https://api.mercadolibre.com/users/me

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:

  1. Autenticate con tu usuario de Mercado Libre:

    2. Notas:
    - Puedes utilizar un usuario de test.
    - Recuerda que el usuario que inicie sesión debe ser administrador, para que el access token obtenido tenga los permisos suficientes para realizar las consultas.
    - Si el usuario es un operador/colaborador, el grant no será válido y recibirás el error invalid_operator_user_id.
    - Los siguientes eventos pueden invalidar un access token antes del tiempo de expiración:
    • Cambio de contraseña por parte del usuario.

    • Actualización del App Secret por parte de una aplicación.
    • Revocación de permisos a tu aplicación por parte del usuario.

  2. Coloca la siguiente URL en la ventana de tu navegador para obtener la autorización:
    3. https://auth.mercadolibre.com.ar/authorization?response_type=code&client_id=$APP_ID&redirect_uri=$YOUR_URL
    Notas:
    - El atributo YOUR_URL se completa con el valor que se agregó cuando se creó la aplicación.



    - APP_ID: Una vez creada la aplicación, será identificada mediante un ID.

    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:

    https://auth.mercadolibre.com.ar/authorization?response_type=code&client_id=$APP_ID&redirect_uri=https://mercadolibre.com.ar
    Importante:
    El redirect_uri tiene que coincidir exactamente con el que se ingresó cuando se creó la aplicación, para evitar recibir el siguiente error:


  3. Como último paso, el usuario será redirigido a la siguiente pantalla donde se le solicitará que vincule la aplicación con su cuenta.


Si revisamos la URL, se puede observar que se agregó el parámetro code.

https://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.


Nota:
- Ten en cuenta que si el usuario es operador/colaborador, NO será posible que otorgue grant a la aplicación. Recibirás el error invalid_operator_user_id.

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.
En resumen, el proceso que estarás realizando es el siguiente:

flujo_serverside

Referencias

  1. Redirecciona la aplicación a Mercado Libre
  2. No tienes que preocuparte por la autenticación de los usuarios a Mercado Libre, ¡nuestra plataforma se encargará de ello!
  3. Página de autorización
  4. POST para intercambiar el código de autorización por un access token
  5. La API de Mercado Libre intercambia el código de autorización por un access token
  6. 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

Importante:
Necesitarás el app_id que obtuviste al crear tu aplicación. Si aún no lo hiciste, puedes registrar tu aplicación.

  1. 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: 
    2. https://auth.mercadolibre.com.ar/authorization?response_type=code&client_id=$APP_ID&redirect_uri=$YOUR_URL
    Nota:
    En el ejemplo utilizamos el URL para Argentina (MLA) pero si estás trabajando en otros países ten en cuenta cambiar el .com.ar por el dominio del país correspondiente. También puedes conocer los países donde operamos.

    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
  2. 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:
    3. https://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:

    https://YOUR_REDIRECT_URI?code=$SERVER_GENERATED_AUTHORIZATION_CODE&state=$RANDOM_ID

    Ejemplo:

    https://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.


  3. El código de autorización es utilizado para intercambiarlo por un access token.

    4. 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.

Importante:
Para eso, la aplicación debe tener seleccionada la opción offline_access.

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.

Importante:
- Solo permitimos utilizar el último REFRESH_TOKEN generado para hacer el intercambio.
- Para optimizar los procesos de tu desarrollo, te sugerimos que renueves tu access token únicamente cuando pierda validez.

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.
Importante:
Para este último flujo, apenas describimos algunos ejemplos y no todos los casos existentes.

Siguiente: Consulta API Docs.

o regístrate para recibir las últimas novedades sobre nuestra API