Fluxos no mesmo dispositivo e entre dispositivos explicados
Sempre que uma carteira comprova algo a um site, os dois têm de se encontrar. Às vezes já estão no mesmo telemóvel e a passagem é um único toque. Outras vezes o site está numa secretária e a carteira num bolso, e a única ponte entre eles é um código no ecrã. São os fluxos no mesmo dispositivo e entre dispositivos, e quase todas as questões práticas sobre credenciais digitais acabam por depender de qual dos dois se aplica.
Duas formas da mesma troca
O que os dois fluxos têm em comum é tudo o que importa ao negócio: a mesma pergunta é feita, a mesma pessoa aprova e a mesma prova regressa. Nada do que pode pedir, nem daquilo em que pode confiar depois, depende do fluxo em que se encontra.
O que muda é o percurso. Num, a carteira está à distância de um toque e devolve a resposta diretamente à página que perguntou. No outro, a resposta viaja de um segundo dispositivo para os seus servidores, e a página que a pessoa está a ver tem de ser informada de que ela chegou.
No mesmo dispositivo
Um telemóvel. Site e carteira no mesmo ecrã.
- O visitante está no site, no navegador do telemóvel, e pede para comprovar algo.
- O site abre a carteira através de um deep link ou de um redirecionamento.
- A carteira mostra quem está a pedir e para quê, e o visitante aprova.
- A carteira redireciona de volta para o site com a resposta, na mesma sessão do navegador em que tudo começou.
Entre dispositivos
Dois dispositivos. Site num computador, carteira num telemóvel.
- O visitante está no site, num navegador de computador, e pede para comprovar algo.
- O site mostra um código QR que contém o pedido.
- A carteira no telemóvel lê o código, mostra quem está a pedir e o visitante aprova.
- A carteira envia a resposta para o backend do site, que avisa a página no computador de que a troca terminou.
Quando acontece cada um
Não é o seu serviço que escolhe. Um cliente que abre a sua página de onboarding no telemóvel durante a viagem para o trabalho está num fluxo no mesmo dispositivo. O mesmo cliente, a terminar o mesmo formulário numa secretária na manhã seguinte, está num fluxo entre dispositivos. A carteira vive num telemóvel, por isso o fluxo acompanha o local onde decorre o resto do trabalho.
É por isso que ambos os protocolos do ecossistema europeu descrevem os dois. A apresentação, em que pede a alguém que comprove algo, nomeia explicitamente os dois fluxos. A emissão, em que entrega uma credencial a alguém, faz a mesma distinção para a oferta que a inicia: pode surgir no dispositivo onde está a carteira ou chegar por qualquer outra via, até numa carta com um código impresso.
Um serviço usado apenas dentro da sua organização, em computadores geridos, pode razoavelmente arrancar com um só fluxo. Tudo aquilo a que um cidadão ou cliente acede nos seus próprios termos precisa de ambos, e um serviço que só funciona de uma forma será reportado como avariado, não como não suportado.
O que cada um exige de quem o utiliza
O fluxo no mesmo dispositivo é o caminho mais curto. Não há segundo ecrã, nem câmara, nem aquele momento de olhar de um dispositivo para o outro, e a pessoa acaba onde começou. Quando falha, costuma falhar cedo e de forma visível: não há carteira instalada, ou o link abre algo que nem sequer é uma carteira.
O fluxo entre dispositivos custa uma leitura de código, mas oferece algo concreto. A pessoa fica no ecrã grande onde estava a preencher um formulário extenso, a ler um contrato ou a comparar opções, e só a prova passa para o telemóvel. Para tudo o que exija mais de um minuto de escrita, esse é o melhor sítio para estar.
As suas falhas são mais discretas e merecem ser previstas no design. Um código que expirou enquanto alguém procurava o telemóvel, um telemóvel sem rede, uma câmara que não foca. A página que mostra o código deve indicar durante quanto tempo é válido, oferecer um novo sem perder o formulário por baixo e nunca deixar a pessoa na dúvida sobre se algo aconteceu.
Onde os dois diferem de facto: segurança
Num fluxo no mesmo dispositivo, a resposta regressa pelo caminho que a pessoa percorreu: um redirecionamento, no dispositivo onde corre a carteira, para a sessão do navegador que iniciou a troca. Quem copie o pedido do próprio ecrã não tem forma de receber o resultado, porque este é entregue ao dispositivo que fez a aprovação.
Num fluxo entre dispositivos, a resposta nem sequer volta pelo navegador. Vai do telemóvel para os seus servidores, fora da vista da página que mostrou o código. É aí que está a falha: se não associar o código à sessão que o mostrou, o seu serviço não consegue distinguir a pessoa que tem à frente de alguém que colocou o mesmo código diante de uma vítima e esperou.
Esse ataque tem nome e tem solução. O código tem de pertencer a uma sessão, e só a uma, e um resultado que chegue para qualquer outra sessão tem de ser recusado. São poucas linhas de reflexão na fase de design e uma falha conhecida se for ignorado, e é por isso que o IETF escreveu uma best current practice para fluxos entre dispositivos em vez de deixar a questão a cada implementação.
O segundo risco é o phishing, e está no próprio código. Um quadrado a preto e branco não diz nada à pessoa sobre quem está do outro lado, por isso um código impresso num autocolante e colado sobre um verdadeiro é um ataque credível. A defesa é que a carteira, e não o código, identifica a organização que pede e enumera exatamente o que pretende antes de qualquer partilha. A emissão acrescenta mais uma proteção: uma oferta pode exigir um código curto entregue pelo canal que já identificou a pessoa, de modo que uma oferta intercetada pelo caminho não possa ser resgatada por mais ninguém.
O que isto significa para si
Parte confiante
Planeie ambos desde o início. O trabalho extra está no seu front end e na associação do código a uma sessão, não numa segunda integração, e acrescentar essa associação mais tarde é precisamente a parte que corre mal.
Emissor
Decida como a sua oferta chega às pessoas. No ecrã ao lado de um login, num e-mail ou em papel, cada via cai num fluxo diferente, e as que saem do seu canal são as que precisam de um código separado para serem resgatadas.
Titular da carteira
Leia o que a carteira lhe mostra, não o que a página ou o código afirmam. A carteira é o único sítio que identifica quem está a pedir e o que quer, e é o último momento em que pode dizer não.
Termos relacionados
Perguntas frequentes
Quem decide que fluxo é utilizado?
Decide a situação, não uma configuração. Se a pessoa já está no dispositivo onde tem a carteira, o site passa a vez diretamente. Se está num computador e a carteira está no bolso, a única forma de fazer a ponte é um código para ler. Um serviço aberto ao público vai deparar-se com ambos logo na primeira semana.
Suportar ambos significa desenvolver tudo duas vezes?
Não. O pedido que faz e a resposta que verifica são iguais nos dois casos. O que muda é a forma como o pedido chega à carteira e como a resposta volta à sua página: um redirecionamento que o navegador segue, ou um código no ecrã mais uma forma de essa página saber que a troca terminou. Na prática, é um caminho adicional no seu front end, não uma segunda integração.
É seguro usar um código QR para isto?
É seguro quando a troca à sua volta está bem construída. Um código, por si só, não diz nada à pessoa sobre quem está a pedir, por isso têm de se verificar duas coisas: a carteira tem de mostrar a identidade da organização que pede antes de qualquer partilha, e o seu próprio serviço tem de recusar uma resposta que chegue para uma sessão diferente daquela que mostrou o código. Ambas são prática corrente e ambas estão descritas nas especificações.
Uma verificação ao balcão é um fluxo entre dispositivos?
Não, é um terceiro caso. Os fluxos no mesmo dispositivo e entre dispositivos descrevem ambos uma troca pela internet. Uma verificação presencial, com os dois dispositivos lado a lado, usa em vez disso uma norma de proximidade por Bluetooth ou NFC. Para quem segura o telemóvel parece semelhante, mas nada passa pelo seu site.
Fontes
Esta página tem caráter informativo e não constitui aconselhamento jurídico. Para orientação oficial, consulte diretamente as especificações da OpenID e do IETF.