O seu cliente precisa de criar mais uma palavra-passe para usar a sua app?
Antes de responder, decida o que precisa realmente de ficar associado a uma pessoa. Consultar um catálogo pode não justificar uma conta. Aceder a contratos, alterar uma reserva ou consultar documentos privados já pede outra abordagem.
A nossa recomendação é escolher o método de entrada juntamente com a recuperação de acesso. Um login não está resolvido porque funciona no telemóvel de quem o desenvolveu. Para aprovar a solução, peça também que lhe mostrem o que acontece quando o cliente troca de equipamento, perde uma credencial ou já tem conta no seu website.
Para uma empresa portuguesa que vai investir numa app para iPhone e Android, estas decisões devem entrar na proposta de desenvolvimento. Não as deixe para quando alguém perguntar que botões colocar no ecrã inicial.
Primeiro, separe a conta da forma de entrar
Imagine uma empresa de aluguer de instrumentos musicais. A app permite consultar instrumentos disponíveis, acompanhar contratos e pedir uma extensão do aluguer. É um exemplo hipotético, mas útil para distinguir duas coisas.
A conta é o registo do cliente no serviço. A palavra-passe, a passkey ou a conta de um fornecedor externo são formas de demonstrar que aquela pessoa pode entrar. A OWASP distingue precisamente a identificação do utilizador da verificação da sua identidade através de credenciais. (cheatsheetseries.owasp.org)
Para este projeto, recomendaríamos consulta pública do catálogo e autenticação quando o cliente quiser aceder aos seus contratos. Também pediríamos uma conta comum ao website e às duas apps, em vez de três registos independentes.
Escreva uma primeira decisão simples: «O cliente consegue consultar a oferta sem entrar; precisa de se autenticar para ver ou alterar informação da sua conta.» Se o seu negócio exige identificação desde o primeiro ecrã, registe a razão.
As alternativas não resolvem todas o mesmo problema
Palavra-passe: avalie também o que fica à volta
Uma palavra-passe é um segredo que o utilizador apresenta para entrar. Não é resistente a phishing: pode ser entregue num serviço falso. O NIST recomenda, entre outras medidas, bloquear palavras-passe comuns ou comprometidas e permitir gestores de palavras-passe. Estas orientações são uma referência técnica, não uma obrigação legal geral para empresas portuguesas. (pages.nist.gov)
Se os seus clientes já usam uma palavra-passe no website, recomendamos avaliar a reutilização desse sistema de contas antes de criar outro para a app. Peça que a proposta inclua recuperação, proteção contra tentativas repetidas e preenchimento automático. Não compare apenas o trabalho necessário para desenhar dois campos e um botão.
Passkey: entrar sem escrever uma palavra-passe
Uma passkey usa um par de chaves criptográficas. Na implementação documentada para Android, a chave privada fica num fornecedor de credenciais e a chave pública fica no servidor do serviço. O utilizador pode confirmar a utilização através dos mecanismos de desbloqueio disponíveis no equipamento, como biometria ou PIN. (developer.android.com)
A Apple também documenta a entrada com passkeys em apps. A integração exige associar a aplicação ao domínio do serviço; não consiste apenas em acrescentar um botão com Face ID. (developer.apple.com)
Para uma app nova com utilização recorrente, colocaríamos as passkeys entre as primeiras opções a avaliar. Mas pediríamos uma demonstração em equipamentos representativos dos clientes e um percurso explícito para quem não consegue utilizar a credencial habitual.
Não aceite «sincroniza automaticamente» como resposta suficiente para todas as mudanças de telemóvel. A documentação Android descreve sincronização através do gestor de palavras-passe; isso não dispensa testar as combinações de equipamentos e fornecedores que o projeto pretende suportar. (support.google.com)
Entrar com uma conta externa
O login federado permite usar um fornecedor de identidade, em vez de apresentar uma palavra-passe própria ao serviço. No Android, o Credential Manager reúne mecanismos como passkeys, palavras-passe e entrada com Google numa interface de credenciais. (developer.android.com)
Recomendamos esta hipótese quando houver uma razão concreta para o público escolhido, e não para encher o ecrã de logótipos. Numa app exclusiva para trabalhadores, por exemplo, vale a pena avaliar o sistema de identidade já utilizado pela empresa antes de propor contas pessoais.
Em iPhone, a utilização de determinados serviços externos para criar ou autenticar a conta principal também exige avaliar a regra 4.8 da Apple e as suas exceções. A regra prevê uma opção equivalente com características específicas de privacidade; não significa que qualquer app tenha obrigatoriamente de incluir todos os fornecedores. (developer.apple.com)
Use este quadro para chegar a uma escolha inicial
O quadro seguinte é uma recomendação de seleção, não uma classificação universal de segurança. Use-o para reduzir as alternativas que a equipa terá de demonstrar.
| Situação do seu negócio | Abordagem a avaliar primeiro | Condição para aprovar |
|---|---|---|
| A app serve sobretudo para consultar informação pública | Acesso sem conta nessa parte da app | Identificar exatamente onde passa a ser necessária autenticação |
| Já existe uma área de cliente no website | Reutilização do sistema de identidade existente | O cliente encontra os mesmos dados sem criar outra conta |
| Nova app de utilização frequente | Passkeys como método preferencial | Demonstrar criação, entrada e recuperação nos equipamentos previstos |
| Público que já usa um fornecedor externo relevante | Login federado | Definir associação à conta existente e alternativa de recuperação |
| App reservada a trabalhadores | Identidade empresarial | Demonstrar entrada, alteração de permissões e revogação de acesso |
| Serviço com operações de impacto elevado | Método de entrada combinado com confirmação adicional quando necessária | Separar acesso corrente de ações que exigem nova verificação |
Escolha uma abordagem principal e justifique as alternativas. Se a proposta incluir vários métodos, pergunte que necessidade concreta resolve cada um e como se evita criar contas separadas para a mesma pessoa.
A recuperação de acesso faz parte da escolha
O NIST trata a recuperação como um processo próprio, distinto da autenticação habitual, e prevê métodos como códigos de recuperação, contactos previamente definidos ou nova verificação de identidade. Também prevê notificação após a recuperação. A opção adequada depende do nível de garantia pretendido. (pages.nist.gov)
Na app de aluguer de instrumentos, proporíamos discutir este cenário antes de aprovar o login: um cliente perde o telemóvel, deixa de conseguir usar a credencial habitual e precisa de consultar um contrato em curso.
Quem o ajuda? Que prova é aceite? Que informação pode a equipa de apoio consultar? Quem tem autoridade para restabelecer o acesso?
Recomendamos que estas respostas fiquem num procedimento curto, acompanhado pelo percurso na app. Evite uma solução em que o apoio decide caso a caso apenas com base numa chamada convincente. A recuperação deve ter regras, não depender da confiança pessoal de quem atende.
Peça ainda uma distinção clara entre duas situações: recuperar o acesso à conta e corrigir dados de contacto. Não recomendamos que a simples indicação de um novo endereço de email permita fazer ambas as coisas de uma vez.
Entrar na app não deve autorizar tudo
A autenticação verifica quem entra. A autorização determina a que recursos e ações essa pessoa pode aceder. A OWASP recomenda nova autenticação em situações sensíveis, como alterações críticas da conta, e controlos adicionais após eventos de risco. (cheatsheetseries.owasp.org)
No exemplo do aluguer, propomos separar a consulta do contrato de uma alteração à pessoa autorizada a levantar o instrumento. A primeira é uma ação corrente; a segunda merece uma decisão explícita sobre confirmação e permissões.
Peça à equipa uma lista curta das operações que exigem nova verificação. Não recomendamos interromper todas as consultas com pedidos de confirmação. Prefira justificar cada interrupção pelo impacto da ação.
Para contas empresariais com vários utilizadores, acrescente outra pergunta: quem pode consultar e quem pode alterar? Não aceite a partilha de uma única credencial como desenho de acesso por defeito.
Peça uma demonstração, não apenas uma lista de funcionalidades
Antes de adjudicar a implementação completa, recomendamos uma demonstração que percorra as decisões difíceis. Pode ser um protótipo funcional limitado à autenticação, ligado a um ambiente de testes.
Use este guião na reunião:
- Cliente existente: entra na app e encontra a conta que já utilizava no website.
- Segundo método de entrada: associa outra credencial sem perder o histórico nem criar um registo paralelo.
- Mudança de equipamento: recupera o acesso pelo percurso acordado.
- Credencial indisponível: percebe o passo seguinte sem ficar num ciclo de erros.
- Operação sensível: recebe o pedido de confirmação definido para aquela ação.
- Acesso revogado: deixa de conseguir executar as operações que lhe foram retiradas.
Para cada cenário, registe o resultado esperado e quem o aceita do lado do negócio. Assim, «login incluído» deixa de ser uma expressão vaga na proposta.
Na comparação comercial, peça para separar integração inicial, migração de contas existentes e serviços externos necessários. Se houver cobrança por utilização, exija a unidade usada pelo fornecedor e as condições aplicáveis ao seu projeto. Não faz sentido comparar totais sem saber o que cada proposta está a contar.
A decisão final deve caber numa página: quem precisa de conta, qual é o método principal, que alternativa existe, como se recupera o acesso e que ações pedem nova confirmação. Leve essa página para a discussão sobre o desenvolvimento da sua app para iPhone e Android. Se alguma resposta continuar por decidir, peça que seja validada antes de fechar o âmbito e o preço.