A integração técnica entre Cloudflare Access e um identity provider corporativo leva menos de uma hora na maioria dos casos — troca de metadados, alguns URLs, teste de autenticação. O que leva semanas é o que vem depois: decidir quais grupos têm acesso a quais aplicações, com qual duração de sessão, com qual exigência de MFA, e o que fazer com colaboradores externos em um IdP diferente. A configuração do protocolo é detalhe de documentação. A arquitetura de política é decisão de design.
SAML, OIDC e o que importa na escolha
O Cloudflare Access aceita tanto SAML 2.0 quanto OIDC. Para providers corporativos maiores — Okta, Azure AD, Google Workspace, OneLogin, Ping Identity, JumpCloud — a Cloudflare mantém guias de integração com o mapeamento exato de campos. A escolha entre SAML e OIDC raramente é decisão técnica crítica; ambos funcionam de forma equivalente para o caso de uso de autenticação do Access.
A diferença prática é que OIDC é mais simples de configurar para providers modernos e retorna atributos em formato JWT diretamente. SAML exige mapeamento de atributos no formato de assertion XML, o que adiciona fricção em configurações mais complexas — especialmente quando se quer passar atributos customizados do IdP para usar em políticas. Para integrações novas com Okta ou Azure AD, OIDC é o caminho de menor resistência.
Múltiplos identity providers simultaneamente
Uma capacidade do Access que passa despercebida em projetos iniciais: a mesma organização pode ter múltiplos providers configurados e atribuir providers diferentes a aplicações diferentes. Uma aplicação aceita autenticação via Google Workspace para funcionários e via GitHub para colaboradores externos. Outra restringe exclusivamente ao Okta corporativo. Uma terceira exibe o menu de escolha para o usuário selecionar qual provider usar.
Isso resolve o cenário frequente de empresas com colaboradores em diferentes empresas parceiras, cada uma com seu próprio Azure AD ou Google Workspace. Em vez de criar contas de guest em todos os providers, o Access aceita múltiplos providers com políticas distintas por provider. O limite prático não é técnico — é de gestão: cada provider adicional é um ponto de configuração a manter e um vetor de acesso a monitorar.
Grupos e a sincronização de autorização
Políticas do Access que referenciam grupos puxam a associação diretamente do IdP no momento da autenticação. Uma política "allow: grupo engineering" não é uma lista estática no Cloudflare — é uma verificação contra o grupo no Okta ou Azure AD no momento em que o token de autenticação chega. Quando um colaborador é adicionado ou removido do grupo no IdP, o efeito é imediato na próxima autenticação, sem sincronização manual na plataforma da Cloudflare.
Isso tem consequência operacional importante: o processo de offboarding precisa remover o usuário do IdP, não apenas revogar acesso em cada aplicação individual. Se o usuário for desativado no Okta, todas as políticas do Access que dependem daquele IdP param de funcionar para aquela conta. A sessão ativa continua válida até expirar — o que reforça a importância de configurar durações de sessão adequadas por aplicação.
Duração de sessão e enforcement de MFA por aplicação
A duração de sessão é configurada por aplicação no Access, não globalmente. Para uma aplicação de monitoramento interno de baixa sensibilidade, sete dias é razoável. Para acesso SSH ao ambiente de produção, uma hora de sessão obriga reautenticação frequente, reduzindo a janela de um token comprometido. Para um painel de administração de banco de dados, 15 minutos pode ser mais apropriado.
O MFA pode ser exigido ao nível do Access, independente do que o IdP faz. Se o IdP não enforça MFA por padrão, a política do Access pode exigir que a autenticação tenha utilizado segundo fator — o Access redirecionará o usuário para completar MFA no IdP se o token não incluir essa garantia. Diferentes aplicações podem ter requisitos diferentes de garantia de autenticação sem necessidade de configurar múltiplas políticas de MFA no IdP.
Service tokens para acesso machine-to-machine
Pipelines de CI/CD, agentes de monitoramento, webhooks — qualquer sistema automatizado que precise acessar um recurso protegido pelo Access enfrenta um problema: não há usuário humano para passar pelo fluxo de SSO. O Access resolve isso com service tokens: um par client ID e client secret que identificam um serviço como entidade confiável.
O serviço automatizado inclui o client ID no header CF-Access-Client-Id e o secret em CF-Access-Client-Secret. O Access reconhece o service token, avalia a política associada, e permite ou nega o acesso — gerando evento de auditoria como qualquer outro acesso. Service tokens têm data de expiração configurável e podem ser revogados individualmente sem afetar outros tokens ou usuários.
Como estruturar as políticas antes de ligar
O erro de projeto mais comum na adoção do Access é criar uma política por aplicação sem um modelo de hierarquia. Com dezenas de aplicações internas, manter políticas individuais para cada uma vira carga operacional considerável. A alternativa é definir grupos de acesso reutilizáveis — "acesso básico para todos os funcionários", "acesso elevado para o time de engenharia", "acesso administrativo para SRE" — e aplicá-los como blocos nas políticas individuais de cada aplicação.
A política de acesso de uma nova aplicação pode herdar um grupo base e adicionar condições específicas, como device posture obrigatório ou restrição de horário. Quando o time de engenharia cresce e um novo grupo é criado no IdP, a atualização da política de grupo reutilizável no Access propaga para todas as aplicações que a referenciam automaticamente.
O que precisa estar decidido antes de configurar
A integração técnica com o IdP é o menor dos desafios. O maior é documentar as decisões de política e seus fundamentos antes de ativar o Access em produção. Quais aplicações têm acesso automático para todos os funcionários? Quais exigem aprovação explícita por grupo? Como colaboradores externos de empresas parceiras são tratados? Quem mantém os grupos no IdP alinhados com as políticas do Access?
Essas perguntas não têm resposta técnica — são decisões que a equipe de segurança e o time de produto precisam tomar juntos. Times que chegam à configuração técnica sem ter respondido essas questões geralmente terminam com políticas muito permissivas que replicam o problema da VPN com uma camada de autenticação por cima.