...
A seguir serão apresentados alguns exemplos de fluxos:
FLUXO 1 - Caminho feliz |
---|
Image Modified
|
- O usuário, no navegador, entra na tela de login web
- Após a inserção das credenciais, é efetuada uma requisição ao login-service (*1)
- Caso a autenticação seja realizada com sucesso, será retornada informações dos tokens (access_token e refresh_token) (*2) e será automaticamente redirecionado para o aplicativo padrão (portais, menu, dashboard, entre outros) (*3)
- Com os tokens devidamente armazenados, eles são enviados para o acesso a um determinado endpoint (*4)
- O DSS architeture efetuará a validação do token enviado (*4) e caso esteja tudo OK, o acesso será autorizado com a requisição concluída (*5 e *6).
|
FLUXO 2 - Requisição direta ao front-end |
---|
Image Modified
|
- O usuário, no navegador, acessa diretamente um endereço correspondente a uma tela front-end (menu, dashboard, portal, entre outros) (*1);
- O front-end tenta acessar um endpoint seguro (*2);
- 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);
- O front-end interpreta este tipo de erro e redireciona para a tela de login web para que as credenciais sejam informadas (*4);
- Após a inserção das credenciais, é efetuada uma requisição ao login-service (*5);
- Caso a autenticação seja realizada com sucesso, será retornada informações dos tokens (access_token e refresh_token) (*6) e será automaticamente redirecionado para o endereço de back_to correspondente ao front-end que efetuou o redirecionamento na etapa 4 (*7);
- Com os tokens devidamente armazenados, eles são enviados novamente para o endpoint seguro (*8);
- 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).
|
FLUXO 3 - Requisição com um token inválido e/ou expirado |
---|
Image Modified
|
- O front-end tenta acessar um endpoint seguro (*1);
- 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) (*2);
- O front-end interpreta este tipo de erro e reconhece que existe um refresh_token, portanto tenta efetuar a renovação do token por intermédio do login-service (*3);
- Caso a validação do refresh_token seja concluída com sucesso, serão retornados novos tokens (access_token e refresh_token) (*4)
- Com os tokens devidamente atualizados em seu armazenamento, eles são enviados novamente para o endpoint seguro (*5);
- 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 (*6).
|
04. ARMAZENAMENTO DOS TOKENS
...
Os tokens devem ser armazenados para não houver a necessidade de efetuar sua geração a cada requisição, quanto ao armazenamento, foram consideradas três propostas:
sessionStorage
Capacidade - Capacidade de armazenamento maior 5-10MB
|
- - Possível inviabilidade devido a cross domain
|
- - Abertura de uma nova URL é considerada outra sessão
|
. ...
- , portanto os dados não são repassados
Aviso |
---|
| Devido a característica do DSS, onde os serviços serão distribuídos em diversas portas, esta opção se torna inviável para utilização. |
|
localStorage
PRÓS | CONTRAS |
---|
- Fácil interação
- Capacidade de armazenamento em 5MB.
|
STORAGE (localStorage)
- Fácil interação - Capacidade em 5MB | - Necessidade de gerenciar um cross domain pois o storage é disponível por host e porta - Opções Iframe - Sincronização de eventos (abertura da tela com set da localStorage em cada projeto para receber o parametro) |
Cookies
...
- - Alinhado com futuras entregas do Identity
|
- - Visibilidade entre domínios
|
- - Configurações de visibilidade de acordo com regras de segurança dos próprios cookies
|
- - - Possivel implementação de um cookie opaco
|
- - Pode ter uma lentidão para regatar o valor do cookie
|
05. ANEXOS
RFC000032 - Autenticação Aplicações On-Premises (RASCUNHO)
...