Implementando o logout

Com o JWT não temos o armazenamento do Token. Então como realizar o logout?
O access_token tem um tempo de vida menor, pois está sendo manipulado pelo javascript e mais susceptível a um possível ataque.
Por outro lado o refresh_token tem um tempo de vida maior e é "mais seguro" em relação ao refresh_token.
Nosso logout irá destruir o refresh_token no lado servidor.
A imagem em anexo mostra as configurações da requisição, via Postman para o logout.

Release de correção

Alguns models, 01 arquivo de migration e algumas alterações não foram comitadas. Segue correção.

Adicionando permissões de acesso

Agora apenas usuário autenticados podem fazer requisições, mesmo para a requisição da listagem de Categorias, antes liberada com "permitAll()"; Perceba que "permitAll()" ainda existe na classe ResourceServerConfig porém na classe CategoriaResource o método "listar()" está anotado com "@PreAuthorize("hasAuthoriry('ROLE_PESQUISAR_CATEGORIA')")", viabilizando a listagem apenas para usuários autenticados e com a permissão "ROLE_PESQUISAR_CATEGORIA".

Nesta implementação também podemos ter uma maior segurança quanto aos clientes das aplicaçãoes.
Na classe AuthorizationServerConfig perceba que temos 2 clientes: o cliente angular e o cliente mobile. Para o cliente angular temos 2 escopos: read e write; já para o cliente mobile temos apenas o scope read. Isso significa que mesmo um usuário com permissões avançadas, como o usuário ADMIN, poderá ter seu acesso restringindo de acordo com o cliente utilizado, lembre-se que cliente é diferente de usuário, isso foi comentado em sala de aula.
Na classe CategoriaResource logo acima dos métodos pode-se verificar a anotação @PreAuthorize, nesta anotação, além de passarmos a ROLE cadastrada no banco, podemos também especificar o scope a ser utilizado em cada método.
No Postman é só alterar o username e password (ver figura UserPasswordScopes.jpg) de acordo com os dados no AuthorizationServerConfig.

Movendo o usuário para o banco de dados

Atenção para a imagem com a nova forma de preencher o body da requisição. No body da requisição deverão ser passados os dados de usuário e senha de cada usuário cadastrado no banco de dados.
Admin tem senha admin. Maria tem senha maria. No script do banco a senha está criptografada. Dentro do pacote Util que se encontra dentro do pacote security existe a classe GeradorSenha, nela você pode executar como uma aplicação simples Java passando a senha que deseja encodar, no prompt irá aparecer a senha encodada.
Da forma que está a aplicação agora apenas usuários cadastrados no banco de dados, entretanto, as permissões ainda não estão sendo seguidas, ou seja, usuária MARIA tem as mesmas permissões que o usuário ADMIN, apesar de as permissões serem distintas, trataremos isto na próxima aula.

Criando filtro para CORS

v8.0

Criando filtro para CORS

O que é CORS?

v7.0

O que é CORS?

Movendo o refresh token do cookie para a requisição

Nesta etapa não há mais a necessidade de passar o refresh_token no header.

Movendo o Refresh Token para o Cookie

v5.0

Movendo o refresh token do cookie para a requisição

Renovando o access token com o refresh token

Agora a saída do novo access token fornece também o refresh_token

Configuranto JWT no projeto

Permanece a estrutura anterior do POSTMAN o token gerado é em formato distinto da versão anterior.
https://jwt.io para debug do token gerado.