SSO corporativo (OIDC) & autenticação multifator (MFA)
Localização da configuração
Os administradores da empresa acessam esses parâmetros via Configurações → Empresa, nas abas Métodos de conexão e Autenticação em duas etapas.
Se os seus usuários fazem logon atrás de uma VPN, de um proxy corporativo ou de um firewall com inspeção SSL, alguns fluxos do SSO podem ser bloqueados ou alterados (cookie de estado removido, domínios de identidade inacessíveis). O sintoma típico é um logon que falha ou entra em loop — enquanto o SSO funciona sem a VPN. Compartilhe a matriz de fluxos de rede com a sua equipe de rede para permitir os domínios necessários sem inspeção SSL nem reescrita de cookies.
Métodos de conexão disponíveis
O FoxPlan suporta várias abordagens de autenticação:
- Senha
- Google Sign-in
- Microsoft Sign-in
- SSO corporativo (OIDC)
Os administradores da empresa conservam sempre a conexão por senha, mesmo quando ela está desativada para a empresa. Isso evita ficar trancado fora do FoxPlan se o provedor de identidade ficar indisponível.
Exceções: manter a senha para determinados usuários
Ao migrar sua organização para o SSO, você pode desativar a conexão por senha para todos, exceto uma lista de usuários designados.
Desmarque Senha: um seletor «Exceções: usuários que mantêm a senha» aparece então abaixo das caixas de seleção. Escolha nele os usuários em questão e depois salve.

Esses usuários continuarão vendo o campo de senha na tela de conexão, enquanto todos os outros deverão passar pelo SSO ou pela conexão Google/Microsoft.
Casos de uso típicos:
- Contas de emergência («break-glass») em caso de pane do provedor de identidade
- Prestadores ou externos ausentes do seu diretório corporativo
- Migração progressiva: migrar as equipes para o SSO em ondas
O seletor só é visível se o método Senha estiver desmarcado: enquanto ele estiver ativo, já se aplica a todos e nenhuma exceção é necessária.
Opções de MFA
As organizações podem escolher entre:
- TOTP (compatível com Google Authenticator, Microsoft Authenticator, Okta, Keycloak)
- Verificação por e-mail
- Sem MFA
Escopo: a quem se aplica a autenticação em duas etapas
Assim que um método é selecionado (TOTP ou E-mail), uma seção «Aplica-se a» permite escolher a população em questão:
| Opção | Efeito |
|---|---|
| Todos os usuários | A autenticação em duas etapas se impõe a toda a empresa (comportamento padrão). |
| Somente os usuários listados | Apenas os usuários selecionados passam pela autenticação em duas etapas. |
| Todos os usuários exceto os listados | A autenticação em duas etapas se aplica a todos, exceto aos usuários selecionados. |
Para os dois últimos modos, um seletor permite designar os usuários em questão.

Casos de uso típicos:
- Implantação progressiva: começar por «Somente os usuários listados» com uma equipe piloto, depois passar para «Todos os usuários».
- Reforço direcionado: exigir a autenticação em duas etapas apenas para os administradores e os perfis sensíveis.
- Exclusões técnicas: dispensar contas que não podem responder a um desafio MFA (contas de serviço, terminais compartilhados) via «Todos os usuários exceto os listados».
O escopo é aplicado no lado do servidor: um usuário fora do escopo se conecta diretamente, sem desafio MFA, mesmo se um método estiver ativo para a empresa.
No modo «Todos os usuários exceto os listados», cada usuário excluído constitui um enfraquecimento do nível de segurança. Revise essa lista regularmente.
Fluxo de conexão
- O usuário digita seu e-mail e continua
- O FoxPlan identifica a empresa associada
- Os métodos de autenticação disponíveis para essa organização são exibidos
- O usuário escolhe Senha ou SSO conforme as opções ativadas
Para os fluxos por senha, os desafios MFA se aplicam. Os fluxos SSO delegam a autenticação ao provedor de identidade.
Configuração do SSO corporativo (OIDC)
O FoxPlan suporta os provedores OIDC: Okta, Keycloak, Google, Microsoft e implementações personalizadas.
No lado do provedor de identidade:
- Criar uma aplicação OIDC do tipo Web
- URL de redirecionamento:
{origin}/login/oauth2/code/{registrationId} - Coletar Client ID, Client Secret (ou certificado, ver abaixo) e Issuer URI
No lado do formulário SSO do FoxPlan:
- Seleção do provedor
- Nome de exibição
- Client ID
- Autenticação do cliente: segredo partilhado ou certificado
- Issuer URI
- Scopes:
openid,profile,email - Atributo username (tipicamente
subouemail) - Toggle de ativação
Autenticação do cliente: segredo ou certificado
A troca do código de autorização por um token é a única chamada que o FoxPlan dirige diretamente ao fornecedor de identidade, de servidor para servidor. O FoxPlan tem de se identificar nela, e o campo Autenticação do cliente oferece duas formas de o fazer.
Segredo do cliente (predefinição). Um segredo partilhado, introduzido de ambos os lados. É o modo histórico, e nada muda para as configurações existentes: sem escolha explícita, mantêm-se assim.
Certificado (chave privada). O FoxPlan assina uma asserção JWT com uma chave privada e o
fornecedor verifica-a com o certificado público que aí declarou (private_key_jwt, RFC 7523). O
segredo nunca circula pela rede — razão pela qual muitas dire ções de informática proíbem hoje os
segredos de cliente.
Surgem então dois campos:
- Certificado do cliente: o certificado X.509 em formato PEM. É a metade pública, que deve ser igualmente carregada no seu fornecedor de identidade (no Entra ID: Certificates & secrets → Certificates).
- Chave privada: em formato PKCS#8 não cifrado, o que começa por
-----BEGIN PRIVATE KEY-----. Uma chave PKCS#1 (BEGIN RSA PRIVATE KEY) ou protegida por palavra-passe é recusada, com o comando de conversão a aplicar.
Para gerar um par:
openssl req -x509 -newkey rsa:2048 -keyout chave.pem -out certificado.pem -days 730 -nodes -subj "/CN=foxplan-sso"
openssl pkcs8 -topk8 -nocrypt -in chave.pem -out chave-pkcs8.pem
Declare certificado.pem no fornecedor e cole chave-pkcs8.pem no FoxPlan.
A chave privada é cifrada na base de dados, nunca é devolvida pela API e nunca volta a ser mostrada: ao editar, deixar o campo vazio mantém a chave guardada. O certificado, esse, é público e continua visível.
Ao contrário de um segredo, um certificado tem data de fim. Passada essa data, o SSO para de vez.
A data de expiração está por isso sempre à vista: a lista de configurações inclui uma coluna Autenticação que indica, para cada SSO, se se autentica com segredo ou com certificado — e neste último caso a data de expiração, a laranja no mês que a antecede e a vermelho depois de passada. Essa data nunca é introduzida à mão: é lida do próprio certificado sempre que é apresentada, a única fonte que não pode divergir da realidade. Verificar a configuração dá o detalhe completo, impressão digital incluída.
Configuração por provedor
Google — Issuer URI: https://accounts.google.com
Microsoft / Azure — Issuer: https://login.microsoftonline.com/{tenantId}/v2.0
Okta — App do tipo Web com atribuição e políticas de acesso apropriadas
Keycloak — Issuer URI do realm, flow Authorization Code configurado
Ser avisado antes da expiração
A apresentação da data pressupõe que alguém vá vê-la. Por isso o FoxPlan avisa por iniciativa própria: é enviado um e-mail aos administradores da empresa em três momentos — trinta dias, sete dias e no dia em que o certificado expirou. A mensagem nomeia o fornecedor em causa, indica a data e remete para o ecrã de configuração.
Cada patamar é anunciado apenas uma vez: a varredura retém o que já enviou. Assim que o certificado é renovado — voltando a expiração a ultrapassar os trinta dias — o contador rearma-se sozinho para o certificado seguinte. Não é preciso fazer nada.
Se não houver nenhum administrador de empresa declarado, não sai qualquer e-mail: mais uma razão para manter essa lista atualizada nos membros da empresa.
Quando a ligação falha
O utilizador cuja ligação SSO falha regressa ao ecrã de início de sessão com uma frase que nomeia a causa, e não com um código devolvido pelo fornecedor de identidade:
| O que o utilizador vê | O que fazer |
|---|---|
| O certificado de ligação expirou | Renovar o certificado e voltar a carregá-lo de ambos os lados |
| O certificado não pode ser utilizado | Verificar se a chave privada corresponde ao certificado |
| O fornecedor recusou as credenciais do FoxPlan | O segredo foi alterado no fornecedor, ou o certificado não está lá declarado |
| Nenhuma ligação SSO ativa | A configuração está desativada ou não existe |
| O fornecedor recusou o acesso | A conta não está autorizada na aplicação do lado do fornecedor |
O detalhe técnico — mensagem exata do fornecedor, rasto completo — fica nos registos do servidor, para o suporte. O utilizador recebe uma frase que lhe diz a quem se dirigir.
Verificar a configuração antes de testar
Cada configuração da lista tem um botão Verificar a configuração. Abre um relatório que não sai do ecrã e que não tenta qualquer ligação:
- os URL a declarar no fornecedor de identidade, com um botão de cópia: o URL de redirecionamento e o URL de arranque da ligação. São exatamente os que a aplicação vai utilizar, não é preciso reconstruí-los à mão;
- os controlos de coerência: campos obrigatórios preenchidos, documento de descoberta lido a partir do servidor, emissor e pontos de acesso conformes com o que o fornecedor publica. Com autenticação por certificado, o relatório verifica ainda que a chave privada corresponde ao certificado, mostra a impressão digital SHA-1 — a mesma que a consola do fornecedor apresenta — e assinala um certificado expirado ou prestes a expirar.
Três níveis: verde quando está conforme, laranja para um ponto a observar, vermelho para o que impedirá a ligação. O detalhe apresentado à direita de cada linha é o dado em bruto — URL, estado HTTP, mensagem do fornecedor — aquele que se transmite ao suporte.
Um controlo pode ser assinalado como «URL não sondado»: o servidor só contacta endereços públicos em
https, e a configuração não está em causa.
Este relatório é apenas de leitura: nunca altera a configuração.
Resolução de problemas
Verifique estes elementos em caso de problema de autenticação:
- A URL de redirecionamento corresponde exatamente entre o IdP e o FoxPlan
- A configuração SSO está de fato ativada
- O e-mail do usuário pertence à empresa correta
- Para Okta/Azure/Keycloak, verifique a atribuição e a conformidade com as policies
- Para os usuários Senha+MFA, verifique o cadastro (segredo TOTP ou e-mail válido)