Pessoa
Daniel Fett
Consultor de segurança especializado em identidade e segurança de protocolos web, além de colaborador nos trabalhos de OAuth e OpenID Connect da OpenID Foundation e do IETF. Seu registro oficial no IETF inclui as RFCs 9207, 9449, 9700, 9901 e 10027.
O que saber primeiro
- Papel públicoConsultor de segurança especializado em identidade e segurança de protocolos web, além de colaborador nos trabalhos de OAuth e OpenID Connect da OpenID Foundation e do IETF. Seu registro oficial no IETF inclui as RFCs 9207, 9449, 9700, 9901 e 10027.Confiança média
- Última verificação31 de ago. de 2026Alta confiança
Informações básicas
- NomeDaniel FettAlta confiança
- Papel públicoConsultor de segurança especializado em identidade e segurança de protocolos web, além de colaborador nos trabalhos de OAuth e OpenID Connect da OpenID Foundation e do IETF. Seu registro oficial no IETF inclui as RFCs 9207, 9449, 9700, 9901 e 10027.Confiança média
- Última verificação31 de ago. de 2026Alta confiança
Entidades, projetos e recursos relacionados
- Contexto editorialDaniel Fett e o campo de emissor que nomeava o servidor, não o token, Um callback OAuth pode trazer o `state` correto e um código de autorização verdadeiro e, mesmo assim, estar a caminho do servidor errado. A RFC 9207 acrescenta uma comparação antes que o erro vire vazamento: o emissor indicado na resposta é o mesmo que o cliente registrou no início do fluxo?Confiança média
- Contexto editorialDaniel Fett: a MFA autenticou o usuário, não o contexto do QR, A vítima não digitou a senha em uma página falsa. Ela chegou ao serviço verdadeiro, concluiu o segundo fator e autorizou uma solicitação real. O erro estava na origem da solicitação: quem a havia iniciado era o invasor.Confiança média