Prompting Secure Authentication Flows: OAuth, SSO, e MFA na Prática

Imagine que o seu utilizador está a tentar transferir dinheiro do banco online. Ele já fez login há duas horas, mas agora precisa de confirmar uma operação crítica. Deveria ter de escrever a palavra-passe novamente? E se tiver de introduzir um código de verificação em cada clique num botão diferente? A resposta curta é: depende do contexto. É aqui que o conceito de prompting em fluxos de autenticação segura entra em cena. Não se trata apenas de mostrar uma caixa de diálogo; é sobre decidir exatamente quando, como e porquê pedir ao utilizador para autenticar-se novamente.

Neste artigo, vamos desmontar como funcionam os pilares modernos de identidade digital: OAuth 2.0, Single Sign-On (SSO) e Multi-Factor Authentication (MFA). Vamos ver como parâmetros técnicos específicos controlam a experiência do utilizador, evitando aquela sensação frustrante de "cansaço de prompts" sem comprometer a segurança.

O que significa realmente "Prompting" neste contexto?

Muitas pessoas confundem "prompting" com a interface gráfica de login. Na verdade, no âmbito de protocolos como o OpenID Connect (OIDC), prompting refere-se aos sinais enviados pela aplicação cliente para o servidor de identidade. Estes sinais ditam se o utilizador deve interagir ou se o sistema deve usar sessões existentes silenciosamente.

Pense nisso como um controlo remoto. O servidor de identidade tem regras predefinidas (por exemplo, "mantenha a sessão ativa por 8 horas"). Mas a aplicação pode enviar instruções específicas para sobrescrever essas regras temporariamente. Se a aplicação envia prompt=login, está a dizer ao servidor: "Ignore qualquer cookie de sessão existente e force o utilizador a entrar desde o início". Se não enviar nada, o servidor assume que pode reutilizar a sessão atual, tornando a transição entre aplicações invisível para o utilizador.

Os Blocos de Construção: OAuth 2.0 e OpenID Connect

Para entender o prompting, primeiro precisamos de entender o veículo que transporta estas instruções. O OAuth 2.0 é um framework de autorização que permite a uma aplicação obter acesso limitado a recursos de um utilizador sem partilhar as credenciais principais. Foi lançado em 2012 e tornou-se o padrão da indústria para integrações como "Entrar com Google".

No entanto, o OAuth 2.0 original focava-se apenas em autorização (permissão de acesso). Para adicionar autenticação (quem é o utilizador?), foi criado o OpenID Connect (OIDC), que constrói sobre o OAuth 2.0 para fornecer camadas de autenticação e suporte nativo para SSO. É através do OIDC que temos acesso a parâmetros como prompt e max_age.

Aqui está uma distinção crucial que muitos desenvolvedores perdem de vista:

• Access Tokens: São passaportes de curta duração. Tipicamente vivem entre 15 a 60 minutos. Servem para autorizar chamadas à API.
• Refresh Tokens: Permitem renovar o access token sem incomodar o utilizador novamente. Devem ser rotacionados (substituídos por novos a cada uso) para limitar o dano se forem roubados.
• ID Tokens: Contêm as informações de identidade (claims) do utilizador, incluindo timestamps críticos como o auth_time.

Single Sign-On (SSO): Conveniência vs. Risco

O Single Sign-On (SSO) é um mecanismo que permite ao utilizador autenticar-se uma vez e aceder a múltiplas aplicações federadas sem repetir o processo de login. O objetivo principal é reduzir a fadiga de palavras-passe.

Como funciona tecnicamente? Quando o utilizador faz login na primeira aplicação, o servidor de identidade cria um cookie de sessão SSO. Nas próximas tentativas de login noutras aplicações dentro do mesmo domínio ou federação, o servidor vê este cookie e devolve um token imediatamente, sem mostrar a tela de login.

Isto é ótimo para a produtividade. Um utilizador corporativo pode abrir o email, o CRM e o ERP sem digitar credenciais três vezes. Mas traz um risco: se esse cookie SSO for comprometido, o atacante ganha acesso a todas as aplicações conectadas. É por isso que o SSO raramente existe isolado hoje em dia; ele quase sempre vem acompanhado de controles adicionais de segurança, como veremos a seguir.

MFA: A Camada de Segurança Necessária

A Multi-Factor Authentication (MFA) é uma técnica de segurança que requer dois ou mais fatores distintos (algo que sabe, algo que tem, algo que é) para validar a identidade. Enquanto o SSO reduz o número de logins, a MFA aumenta a garantia de cada login.

A combinação perfeita ocorre quando usamos o SSO para reduzir a frequência dos prompts e a MFA para garantir que, quando pedimos ao utilizador para autenticar-se, estamos a fazer uma verificação robusta. Por exemplo, em vez de pedir a palavra-passe cinco vezes por dia, pedimos-a uma vez com um código TOTP (Time-based One-Time Password) e depois mantemos a sessão segura por várias horas.

Controlando o Comportamento: prompt, max_age e auth_time

Agora chegamos ao coração do assunto: como programar estes comportamentos? O OIDC oferece três ferramentas principais para isto.

1. prompt=login: Este é o interruptor de força bruta. Quando incluído na requisição de autorização, diz ao servidor para ignorar qualquer sessão SSO existente e exigir uma nova autenticação completa. Use-o para ações críticas, como alterar dados de faturação ou gerir dispositivos de segurança.
2. max_age: Este parâmetro aceita um valor em segundos. Diz ao servidor: "Aceite esta sessão apenas se a última autenticação tiver ocorrido há menos de X segundos". Por exemplo, max_age=1800 significa que o utilizador teve de autenticar-se nos últimos 30 minutos. Se a sessão for mais antiga, o servidor força um novo login.
3. auth_time: Esta é uma claim (dado) dentro do ID Token. Contém o timestamp exato da última autenticação. Embora o servidor aplique as regras de max_age, a sua aplicação também deve verificar este campo para garantir que a política interna foi respeitada, especialmente em fluxos complexos com MFA.

Um erro comum é confiar cegamente no servidor. Se um atacante manipular a URL para remover o parâmetro max_age, o servidor pode aceitar uma sessão velha. Portanto, valide sempre o auth_time no lado do cliente antes de liberar acessos sensíveis.

Evitando o Cansaço de Prompts: Boas Práticas de UX

Nada mata a adoção de uma ferramenta tão rápido quanto pedir um código MFA a cada 10 minutos. O objetivo é equilibrar segurança com usabilidade. Aqui estão algumas heurísticas práticas:

• Use Step-Up Authentication: Em vez de encurtar a sessão globalmente, use max_age apenas para operações de alto risco. Permita navegação livre por 8 horas, mas exija max_age=900 (15 minutos) apenas para transferências bancárias.
• Inspeção de Métodos Anteriores: Muitas plataformas permitem verificar quais métodos foram usados no último login. Se o utilizador já completou MFA há 5 minutos, não o obrigue a fazê-lo novamente para um recurso de baixo risco. Verifique se o método 'mfa' está presente nos eventos de autenticação recentes.
• Rotacione Refresh Tokens: Como os access tokens são curtos (15-60 min), dependemos dos refresh tokens para continuidade. Ao rotacioná-los, limitamos a janela de oportunidade para atacantes, permitindo que mantenhamos sessões longas sem aumentar drasticamente o risco.

Lembre-se: o prompting não é um evento binário (login/sair). É um espectro contínuo de confiança. Quanto maior a ação, menor a tolerância para sessões antigas.

Implementação Técnica: Onde Começar

Se estiver a construir um sistema de autenticação do zero, saiba que não é trivial. Requer HTTPS em todos os endpoints, validação rigorosa de parâmetros state e nonce para prevenir CSRF e replay attacks, e gestão cuidadosa de cache de tokens.

Para a maioria das equipes, usar um Identity Provider gerenciado (como Auth0, Microsoft Entra ID ou Curity) simplifica a camada de protocolo, mas ainda exige configuração fina. Você precisará definir:

1. A duração máxima dos access tokens (recomendado: 15-30 minutos).
2. A política de rotação de refresh tokens.
3. As condições específicas que disparam prompt=login.
4. Os valores de max_age para diferentes níveis de risco.

Documente claramente estas políticas para os seus desenvolvedores frontend. Eles precisam saber quando esperar um redirect para o login e quando esperar uma atualização silenciosa do token.

Perguntas Frequentes