Uma sessão válida diz que o usuário passou por algum processo de autenticação. Ela não explica se isso aconteceu há trinta segundos ou há três semanas, nem se a pessoa usou senha, código temporário ou uma chave protegida por hardware.
O Symfony 8.2, ainda em desenvolvimento, prepara uma API para guardar essas duas informações. Os tokens de segurança poderão registrar qual método foi comprovado e quando ele foi usado pela última vez. A aplicação passa a ter dados para exigir uma autenticação mais recente ou mais forte antes de uma operação sensível.
A sessão passa a carregar provas de autenticação
Os nomes dos métodos seguem o vocabulário do RFC 8176. Entre os valores padronizados estão pwd para senha, otp para código de uso único e hwk para prova de posse de uma chave protegida por hardware.
Os autenticadores nativos de formulário, JSON e HTTP Basic registram o método de senha. No autenticador OpenID Connect, o Symfony aproveita o claim amr recebido no ID Token. Autenticadores próprios podem adicionar um AuthenticationMethodBadge ao Passport para informar o método que realmente verificaram.
new AuthenticationMethodBadge(
AuthenticationMethod::HARDWARE_KEY,
)Se a mesma pessoa comprovar métodos diferentes ao longo da sessão, o token mantém as provas anteriores. O método getAuthenticationProofs() devolve um mapa em que cada método aponta para o instante de sua última utilização.
[
'pwd' => 1789140200,
'hwk' => 1789140260,
]Isso permite distinguir duas perguntas que costumavam aparecer misturadas: “essa sessão ainda vale?” e “essa sessão possui uma prova adequada para esta ação?”. Ler uma fatura pode aceitar a sessão atual. Alterar a chave de recuperação ou autorizar uma transferência pode exigir uma chave de segurança usada nos últimos minutos.
Negar o acesso pode iniciar uma reautenticação
A nova integração trabalha com o modo sudo apresentado no Symfony 8.2. Em vez de simplesmente devolver um erro 403 quando falta uma prova, um voter pode chamar requestReAuthentication(). O fluxo de segurança recebe a informação de que o usuário precisa comprovar novamente sua identidade.
A política continua sendo responsabilidade da aplicação. O framework fornece os registros e o mecanismo de reautenticação, mas não decide sozinho quais operações são críticas, quanto tempo uma prova deve valer ou quais métodos atendem a cada risco.
OpenID Connect separa o método pedido do método entregue
Quando a autenticação acontece em um provedor OpenID Connect, a aplicação pode usar acr_values para pedir um contexto mais forte. O exemplo divulgado pelo Symfony solicita phrh, valor definido pelo perfil EAP do OpenID Connect para autenticação resistente a phishing com chave protegida por hardware.
Esse parâmetro é um pedido, não uma prova. O provedor pode responder com outro contexto. Por isso, o Symfony também guarda o claim acr realmente recebido no atributo oidc_acr. O voter precisa conferir o resultado antes de liberar a operação.
O recurso organiza uma decisão que já existia
Reautenticar antes de trocar senha, e-mail, meios de pagamento ou dispositivos confiáveis não é uma ideia nova. A OWASP recomenda uma nova verificação para recursos sensíveis e depois de eventos de risco, como recuperação de conta ou atividade suspeita.
A contribuição do Symfony 8.2 é colocar método e tempo dentro do modelo de segurança do framework, permitindo que voters, autenticadores e provedores externos participem do mesmo fluxo. Como a versão ainda não havia sido lançada quando o recurso foi apresentado, nomes e detalhes devem ser confirmados novamente antes de uma adoção em produção.