Autenticação de API REST com Spring

Programação
, ,
#1

Galera estou desenvolvendo uma API REST com Spring, agora estou implementando a parte de segurança, o cara que está responsável com o APP precisa que além do token ele tenha algumas informações sobre o usuário que estará autenticado, inicialmente nome, cargo e etc…

Por padrão ao se autenticar pelo /oauth/token, ele retorna o seguinte json

{
  "access_token": "valor_do_token",
  "token_type": "bearer",
  "expires_in": 1799,
  "scope": "read write",
  "jti": ""
}

O ideal seria eu alterar esse retorno para ficar por exemplo:

{
  "access_token": "valor_do_token",
  "token_type": "bearer",
  "expires_in": 1799,
  "scope": "read write",
  "jti": "",
  "usuario": {
    "nome": "JOSÉ ANTÔNIO",
    "cargo": "VENDEDOR"
  }
}

Ou criar um novo endpoint para retorna os dados do usuário autenticado?

Se tiverem alguma dica de material de estudo sobre essas tomadas de decisões e práticas também agradeço, acho que meu conhecimento ainda é pouco e tenho muita dúvida na hora de tomar essas decisões.

#2

Este formato seria preferível, pois não haveria necessidade de realizar uma nova requisição somente para buscar dados que teoricamente já poderiam estarem contidos no token JWT assim que o usuário se autenticar.

Veja um exemplo de como adicionar custom claims no token:

#3

Show, entendi!
No caso como você falou que já poderia estar contido, então se eu adicionar ao próprio token, no front ele poderia decodificar e pegar as informações também né?
Porém acho que uma desvantagem de adicionar as informações ao token seria em relação a quantidade, pois quanto mais informações eu colocar o tamanho de caracteres do token iria aumentar, e acho que poderia torna a aplicação mais lenta, por ter que ficar trafegando um token gigante nas requisições.

#4

Sim, poderia tranquilamente!

O tamanho do token não chega a causar lentidão que seja sentida pelo cliente, pelo menos eu nunca tive este tipo de problema, porém deve ser utilizado com sabedoria, no sentido de colocar informações que realmente façam sentido estarem ali, pra não ficar um token “macarrônico” com 321987654123 claims e sendo utilizadas de 1 à 2 claims.

#5

Entendi, valeu Jonathan muito obrigado, sanou minhas dúvidas e vou estudar mais rsrs!
Valeu!