Spring Security: migrar autenticação exige testar o que deve ser recusado

Um guia da InfoQ sobre Spring Security 7 destaca uma mudança que merece teste de migração: na linha 7.1, a verificação de DPoP no resource server precisa ser habilitada explicitamente com .dPoP().[11] Uma aplicação que dependia da ativação automática anterior pode deixar de aplicar a verificação após atualizar.[11] Nesse contexto, um login que continua funcionando diz muito pouco sobre a preservação da proteção.

O que muda para quem desenvolve

DPoP vincula o token a uma chave do cliente e exige uma prova assinada na requisição, com verificação de assinatura, método, URI e vínculo com o token e a chave.[11] O guia também aborda Token Exchange, distinguindo personificação de delegação: o actor_token, quando utilizado, permite registrar a cadeia de quem age pela claim act.[11]

Minha leitura é que esses mecanismos precisam entrar no desenho de autoridade, não apenas na lista de recursos do framework. Para um serviço intermediário que age por um usuário, a pergunta principal é qual poder deve chegar ao próximo serviço. Copiar uma credencial ampla por toda a cadeia não deveria ser a escolha automática.

A consolidação do Spring Authorization Server no Spring Security 7 mantém grupo e artefato Maven, mudando a versão da linha 1.5.x para 7.x; DPoP e Token Exchange já tinham suporte anterior.[11] Não confunda reorganização de projeto com estreia de todos os mecanismos.

Como aplicar

Separe atualização de base e adoção de novas políticas. Monte uma matriz de testes negativos: token sem prova, assinatura com chave errada, método ou URI incompatíveis e repetição da mesma prova. Em ambiente com múltiplos nós, repita a tentativa em instâncias diferentes.

Esse último cenário importa porque o cache padrão contra repetição é local, e a versão descrita permite substituí-lo.[11] A política de nonce também precisa ser implementada quando o cenário a exigir.[11] Antes de escolher uma solução distribuída, explicite a consistência e a janela de proteção que o sistema precisa sustentar.

Na troca de tokens, teste audiência incorreta, concessão não habilitada e tentativa de ampliar escopos. O cliente precisa ter a concessão habilitada, mas audiência, escopos e redução de autoridade continuam sendo responsabilidade da aplicação.[11] Registre o token esperado na saída sem guardar credenciais reais nos resultados de teste.

Cuidados e limites

Um customizador pode sobrescrever indevidamente o vínculo da chave ou conceder mais permissão do que deveria; o framework não impede automaticamente uma política mal escrita.[11] O guia também alerta para mudanças na DSL, Jackson 3 na persistência e configuração de tipos JWT como at+jwt.[11]

A recomendação é atualizar verificadores antes de começar a emitir tokens vinculados e planejar coexistência na implantação gradual.[11] Segurança de migração aparece principalmente nos pedidos recusados. Um teste que só comprova o caminho feliz deixa a decisão mais importante sem evidência.

Fonte

[11] Fonte: InfoQ