Docs Authentication
iFood proporciona los flujos de autorización para que tu aplicación pueda acceder a los recursos de la tienda: el flujo de credenciales de la aplicación y el flujo de código de autorización. A través de estos flujos, tu aplicación podrá adquirir un token de acceso y así poder consumir nuestras APIs.Protocolo HTTPS
Toda comunicación con las API de iFood requiere el uso de HTTPS, , con TLS 1.2 o superior. En caso de que no se cumplan estas condiciones, las API no funcionarán. Además, el envío de credenciales a través de HTTP es una falla de seguridad grave y no se aconseja bajo cualquier circunstancia.
Flujo de credenciales de la aplicación
El flujo de credenciales de la aplicación está destinado a aplicaciones internas/privadas, a las que no se puede acceder directamente a través de Internet. Estas aplicaciones también tienen la capacidad de almacenar la clave secreta en su servidor de forma segura. Un ejemplo de una aplicación adecuada para este flujo son las aplicaciones que se ejecutan dentro de una VPC sin acceso externo, como un servidor que expone las API basadas en las API de iFood.En el flujo de credenciales de la aplicación, para autenticar su aplicación y poder usar nuestras API, necesitará una credencial de la aplicación. La credencial de la aplicación se puede obtener a través del Portal do Desenvolvedor (en el menú Mis aplicaciones, pestaña Credenciales de la aplicación seleccionada).- El clientId representa la identificación única del cliente (en este caso la aplicación);
- El clientSecret s la clave secreta utilizada para obtener un nuevo token de acceso. Esta clave no puede ser expuesta y debe almacenarse de forma segura.
Paso a paso
1. Solicita el token de acceso enviando las credenciales de la aplicación.
Después de la creación de la aplicación en el Portal do Desenvolvedor, la aplicación debe usar tu clientId y clientSecret para solicitar un token de acceso por medio de nuestra API de token.2. La aplicación recibe el token de acceso
La respuesta de la API del token contendrá el token de acceso para el consumo de nuestras API. No generamos tokens de actualización para aplicaciones centralizadas. Puede encontrar más información en nuestras FAQ.3. La aplicación usa un token para acceder a recursos de las tiendas por medio de las APIs de iFood
Una vez se obtenga el token de acceso, se puede usar a través de la autenticación HTTP BearerEn la práctica
El flujo de credenciales de la aplicación es utilizado para aplicaciones centralizadas. El paso a paso práctico de la autenticación por medio del flujo de las credenciales de la aplicación también se encuentra en nuestro canal para desarrolladores, presentado a continuación.Flujo del código de autorización
El flujo del código de autorización está destinado a aplicaciones públicas a las que se puede acceder a través de Internet. Este flujo no depende únicamente de una credencial de la aplicación. En otras palabras, este flujo requiere que la persona que tiene acceso a los recursos de la tienda se pueda autenticar a través del Portal do Parceiro y delegar la autorización solicitada por la aplicación. El flujo del código de autorización se muestra en el siguiente diagrama. Los detalles de cada etapa se encuentran en las subsecciones posteriores.Paso a paso
1. Solicita un código de enlace
El primer paso es solicitar un código de enlace. Este código de enlace se obtiene a través de nuestra API de generación de código de enlace y debe ser la primera solicitud que se realice en la aplicación. Este código de enlace representa un alias para su aplicación. Posteriormente, este código es utilizado en el Portal do Parceiro por la persona propietaria de la tienda para que pueda autorizar la aplicación para acceder a los recursos de la tienda.2. Reciba un código de enlace del verificador de código
Además del código de enlace, presentado anteriormente, la misma API de código de enlace también devuelve el código de verificación. Este código sirve para aumentar la seguridad en la solicitud del token de acceso. Por lo tanto, la aplicación necesita que el código se mantenga de forma segura hasta llegar al paso de la obtención del token, que depende del código de verificación para que sea generado.3. Use el código de enlace en el Portal do Parceiro
Tu aplicación debería poder mostrar el código de enlace y la URL de verificación a los usuarios para que puedan ingresar este código en el Portal do Parceiro. Al ingresar el código de enlace, la persona podrá autorizar (o no) el acceso de su aplicación a los recursos de la tienda.4. Después de autorizar a la aplicación, el código de autorización se ingresa en la aplicación
Una vez que tu aplicación sea autorizada por la persona propietaria de la tienda, la persona recibirá un código de autorización en el mismo Portal do Parceiro. Este código debe ser ingresado en tu aplicación para que así, posteriormente, la aplicación pueda solicitar un token de acceso.5. Solicita el token de acceso con el código de autorización y el código verificador
Una vez que tu aplicación obtenga el código de autorización, que ingresa la persona propietaria de la tienda, tu aplicación debe enviar no solo el código de autorización, sino también el código de verificación, obtenido anteriormente junto con el código de enlace, a nuestra API de token6. La aplicación recibe el token de acceso y el token de actualización
Una vez el código de autorización y el código de verificación sean válidos, tu aplicación no solo obtendrá el token de acceso, sino también, el refresh token. Para que el usuario no tenga que pasar por los pasos anteriores cuando el token de acceso expire, es necesario que la aplicación pueda usar el token de actualización posteriormente y de esta manera obtener un nuevo token de acceso.7. La aplicación usa un token para acceder a los recursos de las tiendas a través de las API de iFood
Una vez se obtiene el token de acceso, puede usarlo a través de la autenticación HTTP del tipo Bearer.8. La aplicación actualiza el token de acceso con el token de actualización
Antes de que el token de acceso expire, debe actualizarlo llamando a la API de token con grantType refresh_token, las credenciales del clientId y clientSecret, y el token de actualización obtenido en el paso 6.En la práctica
El flujo de código de autorización es utilizado para las aplicaciones distribuidas. El paso a paso práctico de la autenticación mediante flujo de código de autorización también se encuentra en nuestro canal para el desarrollador, que se presenta a continuación.Revocación de acceso a aplicaciones distribuidas
Para las aplicaciones que usan el flujo de código de autorización, solo el usuario que autorizó la aplicación puede revocar el acceso a la aplicación.
Validar permisos
Cada vez que tu aplicación recibe un nuevo permiso de algún merchant, es necesario solicitar un nuevo token para que su nuevoaccess_token tenga permiso en ese merchant recién agregado.Después de generar este nuevo access_token, si tu aplicación tiene permiso en el módulo de merchant puedes consultar en el Endpoint de la listagem de merchants para validar si tu nuevo access_token tiene permiso en el nuevo merchant.Tiempo de prolongación de nuevos permisos
Cuando un nuevo permiso es autorizado/revocado, estos datos pueden tardar hasta 10 minutos en propagarse a toda la plataforma. En caso de que el nuevo merchant aún no aparezca en la lista de merchants sugerida anteriormente, espera 10 minutos y genera un nuevo
access_token. Estamos trabajando para reducir este tiempo y pronto pondremos a disposición esta actualización.Expiración de códigos y tokens
Al solicitar con éxito un código (de enlace o autorización) o token (acceso o actualización), la devolución contendrá no solo el código o token, sino también un atributoexpiresIn, que representa el período de validez de la devolución. La siguiente tabla presenta los tiempos de expiración predeterminados para cada token y código.| Token/código | Expiración |
|---|---|
| Token de acesso | 3 horas |
| Token de actualización | 168 horas |
| Código de enlace | 10 minutos |
| Código de autorización | 5 minutos |
Los tiempos de caducidad pueden cambiar en cualquier momento.Es importante que implemente la renovación del token de acuerdo con la respuesta que obtenida de las APIs o considerando el
expiresIn, ya que estos tiempos pueden ser alterados en cualquier momento. Una buena práctica es programar la renovación o generación de un nuevo token con base en el expiresIn obtenido junto al accessToken o cuando algún Endpoint de la API devuelva 401.Rate Limit
No necesitas generar un nuevo token hasta que no haya expirado el anterior. Ten cuidado de no solicitar un nuevo token antes de cada solicitud en la API para no ser bloqueado.