Histórico da Página
...
- Realize uma requisição POST ao endpoint http(s)://{dominio}:{porta}/api/connect/token/ via Postman, SoapUi, ou outro programa que realize requisições HTTP REST.
- No corpo da requisição envie um JSON explicitando usuário e senha do RM para qual a autenticação está sendo direcionada:
• username
• password
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
curl -X POST --location 'http://localhost:8051/api/connect/token' --header 'Content-Type: application/json' --data '{"grant_type": "password","username": "mestre","password": "totvs"}' |
A requisição deve parecer com a abaixo
...
Gerar Token Informando Alias
Na versão 2306, é possível gerar o um token passando o Alias no Body "service_alias" no corpo da API "connect/token" para alguns casos evitar a utilização toda da configuração necessária para utilizar o subdomainmask, evitando a necessidade de configurar completamente o subdomínio em alguns casos.
"service_alias" = informar o Alias que precisa para gerar o Token.
Abaixo segue a chamada para gerar um token utilizando um "Alias".
Bloco de código | ||||
---|---|---|---|---|
| ||||
{ "grant_type": "password", "username": "mestre", "password": "totvs", "servicealias":"CorporeRM" } |
...
Gerar Token Informando Alias com SubDomainMask
Para gerar o Token corretamente o alias terá que ser igual ao SubdomainMask.
um token informando o "Alias" com o "subdomainMask" corretamente, é necessário que o valor do "serviceAlias" seja exatamente igual ao valor do "subdomainMask".
Por exemplo, se o domínio for "cliente1.site.com" e o valor do "serviceAlias" for "cliente1", o token será gerado corretamente.
O "serviceAlias" é o valor do "Alias" que está cadastrado no arquivo "Alias.dat".
Alias.dat
Caso o domínio seja diferente o token não é gerado.
Exemplo: cliente1.site.com diferente de serviceAlias que é cliente2
Informações | ||
---|---|---|
| ||
Caso o Ambiente ambiente esteja configurado com Multitenancy multitenancy e se a SubDomainMask for diferente a url a "subdomainMask" seja diferente da URL, o token não será gerado. |
Duração do Token
A duração do token de acesso pode ser visualizada na resposta da API de geração de token. Sua duração padrão é de 5 minutos, e pode ser alterada, através da tag JWTTokenExpireMinutes, que pode ser inserida no RM.Host.exe.config, podendo ser configurada entre 1 e 43200 minutos (30 dias).
Já o refresh token tem a duração padrão de 16 horas, e também pode ser alterada, mas através da tag JWTRefreshTokenExpireMinutes, podendo ser configurada entre 1 e 129600 minutos (90 dias).
Nota |
---|
A alteração da duração do token somente está disponível no RM a partir da versão 12.1.2310. |
Renovação do Token
Exemplo de utilização - Sucesso:
...
Token de Segurança gerado com sucesso e pronto para ser utilizado:
Informações |
---|
A partir da versão 12.1.2205, foi adicionado um serviço que é inicializado na subida do "Rm.Host" e executa de 5 em 5 horas. Este serviço executa a limpeza dos Refresh_Tokens expirados da tabela GAPITOKENS. |
Validação de JWT
...
Para confirmar que o token não foi adulterado durante a comunicação entre aplicações e o RM, é necessário validá-lo e para isso, é necessário possuir a chave pública responsável pela assinatura do JWT. Como a assinatura de tokens de segurança do RM funciona de forma assimétrica (Qualquer aplicação é capaz de validar o token recebido pelo RM, através de chaves públicas, porém apenas o RM é capaz de assinar um token de segurança, através de chaves privadas), a API de JWKS fornece a lista de JWK's possíveis para validação do token:
...