Por que o token de acesso ao cache é considerado ruim no oauth2?
Estou seguindo este artigo para revogar o acesso do usuário:
Agora, após a validação do usuário, considere emitir um accesstoken com vida útil de 30 minutos, como mostrado no artigo acima, e com o token de atualização como 1 dia, mas e se o administrador excluir esse usuário em 10 minutos, com 20 minutos ainda restantes, agora, neste caso, preciso revogar o acesso desse usuário.
Para fazer isso, preciso remover essa entrada do usuário da tabela de token de atualização para impedir a solicitação de token de acesso adicional, mas como o tempo de expiração do accesstoken ainda está tendo 20 minutos, o usuário poderá acessar o recurso protegido que está completamente errado.
Então, eu estava pensando em implementar o mecanismo de cache paraarmazenar em cache o token de acesso no servidor e também salvar no banco de dados. Portanto, quando esse usuário é revogado, posso simplesmente remover essa entrada do cache e do banco de dados para impedir que o acesso do usuário acesse o recurso protegido.
Mas essas 2 respostas abaixo estão dizendo que não foi assim que o oauth2 foi projetado:
Revogar o token de acesso do OAuthBearerAuthentication
OAuth2 - complexidade desnecessária com token de atualização
Então, minha pergunta é:
1) Por que o cache de token de acesso não é considerado melhor que o mecanismo de atualização de token e também uma abordagem ruim?
Minha segunda pergunta é baseada nesta resposta abaixo dada por@Hans Z. em que ele está dizendo isso:
Isso necessariamente envolveria o Resource Server (RS) consultando o Authorization Server (AS), o que representa uma enorme sobrecarga.
2) No caso de revogar o acesso de um usuário, por que o RS consultaria o AS porque o AS é apenas para autenticar o usuário e gerar token de acesso conforme esteArtigo?
3) No artigo, existem apenas 2 projetos:
Authentication.api - Autenticando usuário e gerando token de acessoServidor de recursos - validando accesstoken com a ajuda de[Authorize] atributo
No caso acima, qual é o servidor de autorização, então?
Atualização: Decidi usar o token de atualização para revogar o acesso do usuário, caso o usuário seja excluído e também quando o logout do usuário, atualizo o token da tabela de token de atualização devido à sua exigência de que desejamos sair do usuário imediatamente assim que o usuário clicar no logout.
Mas aqui o problema éEu tenho 250 funções associadas ao usuário, portanto, se eu colocar funções no accesstoken, o tamanho do accesstoken será muito grande e não podemos passar o accesstoken tão grande do cabeçalho mas não consigo consultar funções para validar o acesso do usuário a terminais sempre que esse terminal é chamado.
Portanto, este é outro problema que estou enfrentando.