"Desativar no Okta" não é "acesso revogado"

Passo boa parte do meu tempo construindo automação de offboarding. No começo, o momento em que o objeto do usuário virava deactivated parecia a linha de chegada. Desativado significava fora.

Não significa. Existe um vão entre “desativado” e “fora”, e é nesse vão que mora o risco do offboarding.

O que o botão realmente faz

Desativar um usuário no Okta impede autenticações futuras. Amanhã de manhã, quando a pessoa que saiu digitar a senha, nada acontece.

O que ele não faz: não fecha a aba do navegador que ficou aberta. Não revoga refresh tokens OAuth nem personal access tokens. E não diz nada sobre as contas locais nos apps que o Okta nunca provisionou.

Então imagine o último dia de alguém que está saindo. A conta Okta morre às 17h. A sessão na ferramenta de on-call continua viva às 18h. O refresh token no cliente de e-mail segue funcionando até o app que o emitiu decidir o contrário. Nada dramático precisa acontecer. Esse é o comportamento padrão.

Onde o acesso se esconde

Mesmo com SCIM conectado, você está confiando num protocolo com ambiguidade real. O SCIM dá ao app duas formas de ouvir “essa pessoa saiu”: um DELETE no usuário ou um PATCH colocando active em false. Alguns apps fazem soft delete, alguns apagam de vez e destroem a trilha de auditoria, alguns ignoram o DELETE e só respeitam o PATCH.

O Okta abstrai isso por conector, então dois apps atrás do mesmo desligamento podem terminar em estados opostos, e o console mostra um check verde para os dois. O check diz que a chamada foi enviada. Não diz que a conta está desligada.

Caso raro? Levantamentos de ciclo de vida de identidade em 2026 apontam que cerca de 83% dos ex-funcionários ainda mantêm algum acesso a sistemas de um empregador anterior.

O que “revogado” exige de verdade

Revogação é um pipeline com três tarefas: impedir novos logins, matar o acesso vivo, verificar o downstream. A desativação só faz a primeira.

Matar o acesso vivo é uma chamada de API a mais:

POST   /api/v1/users/{userId}/lifecycle/deactivate
DELETE /api/v1/users/{userId}/sessions?oauthTokens=true

A segunda chamada derruba as sessões e revoga os grants OAuth: a aba aberta morre agora, não quando expirar.

Verificação é onde a maioria dos pipelines silencia. O System Log do Okta registra o que cada conector realmente enviou: o evento application.provision.user.deactivate carrega a chamada HTTP de verdade. Teste cada conector com um usuário canário e leia o evento. O status na UI é um resumo escrito para otimistas.

Depois, coloque um relógio nisso: uma desativação que não for seguida das desativações correspondentes no downstream dentro de uma janela definida deve acionar alguém, não esperar o próximo access review.

O botão, revisitado

O botão de desativar faz o que o nome diz: desativa o usuário, no Okta. Cada palavra depois de “no Okta” é trabalho seu.

Nesta semana, numa org de preview: escolha um app com SCIM, crie um usuário canário, desative. Veja qual verbo o conector enviou e se a sessão sobreviveu. Um usuário de teste, um screenshot, e você descobre se o seu offboarding termina num check verde ou em acesso revogado.