Histórico da Página

01. DADOS GERAIS

02. SITUAÇÃO/REQUISITO

Link documentação: https://developer.ifood.com.br/pt-BR/docs/references/#authentication

O Ifood possui duas formas de autenticar (Centralizado e Distribuído)

O tipo Centralizado é uma maneira mais simples, onde nós como TOTVS temos um acesso único que vale para todos os nossos clientes, e é recomendado para quando temos controle sobre o ambiente do cliente (Clientes Cloud)

O tipo Distribuído é recomendado em casos onde não temos acesso ao banco do cliente, no caso de clientes On Premise. Basicamente é uma autenticação com dois fatores. 

No nosso caso, como temos clientes On Premise e Cloud, foi recomendado pelo time do Ifood que usemos o token distribuído.

Na primeira chamada passando os dados do cliente, é obtido pela API um link URL para que o cliente acesse, e após o envio de um código por email, o cliente entra no portal do Ifood. Dentro do Portal, aparece uma mensagem indicando que nós estamos querendo acessar o seu ambiente, e após a autorização do cliente, é gerado um código que deve ser configurado também no WSH. Com esse código em mãos, voltamos na API de autenticação, passando esse código e os demais parâmetros, e obtemos o token.

A primeira chamada é feita no endpoint /oauth/userCode, conforme abaixo:

Retornar os dados da consulta como userCode, que é necessário para a verificação do usuário e obter o código de autorização, que deverirá, juntamente com os dados de conexão utilizados na primeira requisição

O parâmetro grantType deve ser passado como "authorization_code)

Os parâmetros clientId e clientSecret são fornecidos pelo cliente, e deve ser possível configurá-los no WSH, opção de parâmetros

A API retorna uma URL e um código de verificação, destacado acima.

Devemos abrir no navegador do cliente essa URL para que ele siga com o login, e armazenar o código de verificação destacado acima.

Depois que o cliente acessar o portal do Ifood, será apresentada uma mensagem de autorização, e após confirmação, será gerado um código para ele, conforme abaixo:

Deve ser possível também configurar esse código no WSH.

Com o código em mãos, fazemos a requisição no endpoint /oauth/token, da seguinte forma:

Será retornado o accessToken e o refreshToken

Que também será obtidos em tempo de execução do WSH após configurado na rotina 2670

No log serã apresentados os log de tentativa e conexão bem sucedida de refreshToken

Após a configuração do token, o WSH está pronto para ser utilizado nas requisições

03. SOLUÇÃO

• Criado o Fluxo de autenticação via WSH

04. DEMAIS INFORMAÇÕES

05. ASSUNTOS RELACIONADOS

• Como atualizar as rotinas do WinThor?