Para requisitar o token autenticado, o software cliente inicia o fluxo de comunicação através do User-Agent até o Módulo Risk Manager. Então, o "Authorization Request" é enviado ao Módulo Risk Manager. Para isso, ele envia as seguintes informações: response_type, client_id e redirect_uri. O redirect_uri e a URL de retorno fornecidos quando a aplicação é cadastrada no sistema devem ser idênticos.
GET {RMUrl}/APIIntegration/AuthorizeFeatures?client_id=f96f6ebb9ec0446cbc52b079e942a0c7&response_type=code&redirect_uri=http%3A%2F%2Fintranetficticia.com.br%2Fapplication HTTP/1.1
Host: modulo.com
Ao receber o "Authorization Request", o sistema verifica se as informações estão presentes e são válidas. Se a requisição for válida, o usuário é redirecionado para uma tela para autorização do uso das funcionalidades selecionadas no cadastro do software cliente no sistema. Uma vez autorizado, o sistema redireciona o usuário para o redirect_uri fornecido. A resposta é um "Authorization Response" com um código authorization_code gerado pelo sistema.
HTTP/1.1 302 Found
Location: https://intranetficticia.com.br/application?code=f09e5ac6f93e4cb2a2f91f5d2dfa75fa
Se o sistema não validar as informações devido a algum parâmetro inexistente, inválido ou com uma URL de redirecionamento não cadastrada, ele envia um "Authorization Response" ao software cliente com as seguintes informações: error e error_description.
HTTP/1.1 302 Found
Location: https://cliente.exemplo.com.br/cb?error=access_denied
Quando o processo de autorização for concluído, o software cliente envia o "Access Token" ao Módulo Risk Manager. Para isso, ele envia as seguintes informações: grant_type, code, redirect_uri, client_id e client_secret.
POST {RMUrl}/APIIntegration/Token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: modulo.com
Content-Length: 250
Expect: 100-continue
Connection: Keep-Alive
grant_type=authorization_code&
code=f09e5ac6f93e4cb2a2f91f5d2dfa75fa&
client_id=f96f6ebb9ec0446cbc52b079e942a0c7&
client_secret=05e7cb8036554438b43ee52216c453e5&
redirect_uri=http%3A%2F%2Fintranetficticia.com.br%2Fapplication
Ao receber o "Access Token Request", o sistema valida as informações. Por exemplo: verifica a existência do client_id, verifica se o client_secret está associado ao client_id correto e verifica se o authorization_code é válido.
Se o sistema validar as informações, ele retorna com um "Access Token Response" ao software cliente com as seguintes informações: access_token, refresh_token, token_type e expires_in. O sistema armazena o access_token e o refresh_token até as suas datas de expiração. O "Access Token Response" sempre inclui o "HTTP Cache-Control" como "no-store".
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"access_token": "B67F7DF3B6969DEC693F7EDC06BA49B7E5F7F10F",
"refresh_token": "626333EA48628394B1A496984A81335C2740106C",
"token_type": "bearer",
"expires_in": 86400,
}
Ao receber o access_token, o software cliente deve armazená-lo até a sua data de expiração. No acesso autenticado, o token é válido, por padrão, durante 24 horas (86.400 segundos). Uma vez expirado, ele deve ser descartado e não pode ser reutilizado. No acesso autenticado, diversos tokens podem ser requisitados para cada aplicação autorizada.
O refresh_token é uma credencial utilizada para obter acesso a novos tokens. Eles são emitidos para o cliente pelo sistema e são utilizados para obter novos tokens de acesso quando o access_token atual se torna inválido ou expira. Os tokens de atualização são, por padrão, válidos por 6 meses. Depois de expirados, eles devem ser descartados e não podem ser reutilizados.
Tanto os tokens de acesso quanto os tokens de atualização podem ser revogados no sistema. Desse modo, a aplicação cliente deve estar preparada para lidar com respostas de tokens inválidos e para solicitar autorização novamente desde o início.
Se o sistema não validar as informações no "Access Token Request", ele envia um "Authorization Response" ao software cliente com as seguintes informações: error, error_description e error_uri. As informações error_description e error_uri são opcionais. Os códigos de erro HTTP são 401 (se o cliente forneceu credenciais inválidas) ou 400 (se for outro erro).
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
{
"error":"invalid_request"
}