# @eldermoraes on Instagram

- **Type:** Image
- **Original URL:** https://www.instagram.com/p/DV_Q-sgDbMa
- **Gondola URL:** https://gondola.cc/posts/60222432-eldermoraes-instagram
- **Thumbnail:** https://img.gondola.cc/tr:w-,h-,fo-auto/postThumbnails/768932987a.jpg
- **Posted:** 2026-03-17T14:14:30.000+00:00
- **Account Owner:** Elder Moraes (@eldermoraes) — https://gondola.cc/eldermoraes

## Caption

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 tipo de assunto que vale mais do que muito hype de ferramenta nova.

Segurança boa é aquela que reduz risco real sem virar um Frankenstein operacional.

Na sua realidade, bearer token puro ainda dá conta ou já está na hora de subir essa barra?

#java #quarkus #oidc #security #api

## Stats

- **Views:** 0
- **Likes:** 81
- **Shares:** 0
- **Comments:** 2

## Tags

java, oidc, api, security, quarkus

---
Copyright (c) Gondola