Tem muita API Java segura no papel e permissiva demais na prática. Não me entenda mal: Bearer token é simples, funciona bem e resolve muita coisa. Só que ele tem uma fragilidade que muita gente trata como detalhe: quem consegue colocar a mão no token pode tentar reutilizá-lo. É por isso que eu gostei de revisitar a abordagem de sender-constrained tokens no Quarkus OIDC. O ponto mais útil para a sua equipe é o efeito prático: - reduzir risco de replay - aumentar a confiança sobre quem está apresentando o token - fazer isso sem uma novela de código customizado No caso do DPoP, a lógica é amarrar o token a uma prova criptográfica apresentada pelo cliente. Ou seja, não basta sair carregando o token por aí e achar que está tudo resolvido. Agora vem a parte importante: isso não absolve arquitetura ruim. O próprio material do Quarkus deixa claro que a geração da proof, especialmente em SPA, pede cuidado. Mesmo assim, para time Java que já opera API em ambiente corporativo, esse é o ti...