Histórico da Página

...

1. Visão Geral
2. .

01. VISÃO GERAL

O login do produto para o Datasul Smart Services (DSS) deve possuir conceitos unificados para que seu fluxo seja simples, seguro e de fácil utilização.

...

1. A tela de login deve estar hospedada no login-service e não nos clientes, pois deste modo não haverá a necessidade de replicar o conteúdo estático da tela em cada aplicação e facilitará sua reutilização;
2. A autenticação do mesmo será realizado com conceitos do OAuth2, fluxo Resource Owner Password Credentials (ROPC);
   1. Este fluxo estará disponivel enquanto a migração da autenticação com o Fluig Identity não estiver concluída;
   2. Após a liberação do Fluig Identity, será considerada a troca deste modelo de autenticação, possivelmente para o modelo Open ID Connect (OIDC).
3. Para o DSS haverá apenas um cadastro de ROPC do Datasul, visto que, para o sistema apenas esse modelo é necessário;
   1. O provider de autenticação padrão será o banco EMS (login interno com o ERP Datasul);
   2. Será considerado também o provedor de autenticação LDAP.
4. Integrações machine-to-machine também serão consideradas, para estes casos, utilizar o fluxo Client Credentials (CC), também disponível em nosso login-service;
5. A etapa de autorização de acesso será realizada pela validação do token, sendo que este já está implementada na arquitetura do DSS;
6. Por medidas de segurança, o token de acesso (access_token) expirará após um determinado período de tempo;
   1. Como o token de acesso perderá a validade, será necessário a utilização do token de atualização (refresh_token), onde o mesmo conterá um tempo de expiração maior.

03.

...

FLUXOS DE AUTENTICAÇÃO / AUTORIZAÇÃO

O fluxo de autenticação pode seguir alguns caminhos, de acordo com sua requisição inicial e sua necessidade.

...

1. O usuário, no navegador, acessa diretamente um endereço correspondente a uma tela front-end (menu, dashboard, portal, dashboadentre outros) (*1);
2. O front-end tenta acessar um endpoint seguro (*2);
3. Na validação do endpoint, foi verificado que não existem tokens (acesso e atualização) (*2), sendo retornado o erro HTTP Status 401 (não autorizado) (*3);
4. O front-end interpreta este tipo de erro e redireciona para a tela de login web para que as credenciais sejam informadas (*4);
5. Após a inserção das credenciais, é efetuada uma requisição ao login-service (*15);
6. Caso a autenticação seja realizada com sucesso, será retornada informações dos tokens (access_token e refresh_token) (*26) e será automaticamente redirecionado para o endereço de back_to correspondente ao front-end que efetuou o redirecionamento parana oetapa login web4 (*7);
7. Com os tokens devidamente armazenados, eles são enviados novamente para o acesso a um determinado endpointendpoint seguro (*48);
8. O DSS architeture efetuará a validação do token enviado (*48) e caso esteja tudo OK, o acesso será autorizado com a requisição concluída (*59 e *610).

...

1.

...

 O front-end tenta acessar um endpoint seguro (*2);
2. Na validação do endpoint, foi verificado que o token está inválido e/ou expirado (*2), sendo retornado o erro HTTP Status 401 (não autorizado) (*3);
3. O front-end interpreta este tipo de erro e reconhece que existe um refresh_token válido, portanto tenta efetuar a renovação do token por intermédio do login-service (*5);
4. Caso a validação do token de atualização seja concluída com sucesso, serão retornados novos tokens (access_token e refresh_token) (*6)
5. Com os tokens devidamente atualizados em seu armazenamento, eles são enviados novamente para o endpoint seguro (*8);
6. O DSS architeture efetuará a validação do token enviado (*8) e caso esteja tudo OK, o acesso será autorizado com a requisição concluída (*9 e *10).

04

4. O FRONTEND verifica que houve um retorno 401, que não existe um REFRESH TOKEN e o TOTVS
Identity está disponível
5. O FRONTEND gera um STATE e chama a API de AUTHORIZE do ACCOUNTS passando:
grant_type = authorization_code
state = < STATE gerado pelo FRONTEND >
response_type = code
scope = < id da APLICAÇÃO >
client_id = < id da credencial daquela instância da APLICAÇÃO >
redirect_uri = < url da APLICAÇÃO que fará a troca do token >
6. O API de AUTHORIZE do ACCOUNTS valida se a REDIRECT_URI é válida para o CLIENT_ID informado
7. O API de AUTHORIZE do ACCOUNTS gera um CODE e retorna um redirect para a tela de LOGIN do
IDENTITY
8. O IDENTITY apresenta a tela de LOGIN para o USUÁRIO
9. O USUÁRIO informa suas CREDENCIAIS:
e-mail
password

1. Para timeout, logout, erros de login o redirecionamento deve ser feito automaticamente para a url padrão cadastrada no ROPC. Podemos usar a arquitetura do serviço para isso, mas, precisamos analisar melhor para não deixar altamente acoplada a solução.

1. Para timeout, logout, erros de login o redirecionamento deve ser feito automaticamente para a url padrão cadastrada no ROPC. Podemos usar a arquitetura do serviço para isso, mas, precisamos analisar melhor para não deixar altamente acoplada a solução.

1. Ainda teremos que avaliar sobre o refresh token e a melhor estratégia para esse fluxo.

...

. ARMAZENAMENTO DOS TOKENS

STORAGE (sessionStorage)

...

04. FLUXO DE ATUALIZAÇÃO DO TOKEN

05. ANEXOS

RFC000032 - Autenticação Aplicações On-Premises (RASCUNHO)