Requisição de token de acesso anônimo

 

 

Para requisitar o token anônimo, o software cliente envia o "Access Token Request" ao sistema. Para isso, ele envia as seguintes informações: grant_type, client_id e client_secret.

 

POST {RMUrl}/APIIntegration/Token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

Host: modulo.com

Content-Length: 119

Expect: 100-continue

Connection: Keep-Alive

 

client_id=f96f6ebb9ec0446cbc52b079e942a0c7&client_secret=05e7cb8036554438b43ee52216c453e5&grant_type=client_credentials

 

Ao receber o "Access Token Request", o sistema valida as informações. Por exemplo, ele verifica a existência do client_id e se o client_secret está associado ao client_id correto.

Se o sistema validar as informações, ele responde com um "Access Token Response" para a aplicação cliente com as seguintes informações: access_token, token_type e expires_in. O sistema armazena o access_token até a sua data de expiração. O "Access Token Response" sempre inclui o "HTTP Cache-Control" como "no-store".

 

HTTP/1.1 200 OK

Cache-Control: private, no-store

Content-Type: application/json; charset=utf-8

Content-Length: 117

 

{

  "access_token": "A6D1DC6ADD5A75C967C5738E063CE8668AD2492B",

  "token_type": "bearer",

  "expires_in": 86400

}

 

Ao receber o access_token, o software cliente o armazena até a sua data de expiração. No acesso anônimo, o token é válido por 24 horas (86400 segundos). Uma vez expirado, ele deve ser descartado e não pode ser reutilizado. No acesso anônimo, vários tokens podem ser solicitados para cada aplicação autorizada.

Se o sistema não validar as informações, 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"

}