> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/product-docs/product-guide/configuracoes/rmm/sso.md).

# SSO (OIDC)

O RMM DataDike aceita login via **OIDC** (OpenID Connect) contra qualquer provedor compatível. Uma vez habilitado, os usuários da organização entram com o mesmo login que já usam para Microsoft 365, Google Workspace, Okta, etc. — sem senha extra pro RMM.

Aberta em `/sso`.

## Provedores testados

* **Microsoft Entra ID (Azure AD)**
* **Google Workspace**
* **Okta**
* **Keycloak** (auto-hospedado)
* Qualquer IdP OIDC 1.0 com discovery (`/.well-known/openid-configuration`)

## Setup rápido

1. **No IdP**: registre um novo aplicativo/client OIDC. Configure o redirect URI para o valor mostrado na página de SSO do RMM.
2. **No RMM**: em Platform Admin → Single Sign-On, escolha o provedor, cole o **Issuer URL**, **Client ID** e **Client Secret**. Marque Enable e salve.
3. Teste o botão **"Sign in with SSO"** na tela de login.

## JIT Provisioning

Ligado por padrão. Quando um usuário faz login pela primeira vez via SSO e o email dele não existe no RMM, criamos a conta automaticamente com permission group `default` (configurável).

* Se você **não quer** que qualquer usuário do IdP entre, desmarque **"Allow JIT provisioning"** — só quem já tiver conta pré-criada consegue entrar.
* Se você quer restringir por domínio de email, preencha **"Required domain"** (`acme.com`) — só emails desse domínio são aceitos.

## Segurança de trânsito

* Fluxo **Authorization Code + PKCE**
* **State** e **nonce** aleatórios validados na callback
* **Client secret** criptografado com AES-256-GCM em repouso (chave `SETTINGS_ENCRYPTION_KEY`)
* Token OIDC nunca sai do backend — o browser recebe apenas o cookie de sessão do RMM

## O usuário nunca perde acesso pelo SSO

Mesmo com SSO habilitado, o login via **senha + MFA** continua funcionando — SSO é um caminho adicional, não substituto. Se o IdP cair, seus admins ainda entram pela via padrão.

## Convivência com MFA

Se o IdP já força MFA, você pode desligar o MFA no RMM para usuários SSO. Alternativamente, o **Conditional Access** por grupo (`requireMfa`) obriga MFA independentemente do caminho de login — útil para admins de alto privilégio.

## Multi-tenant

Cada organização configura seu próprio IdP. Não há SSO global. Um usuário que troca de organização precisa passar pelo fluxo de convite normal — não há cross-tenancy possível via SSO.

## Auditoria

* Cada login SSO é gravado no Audit Log com IP, provider, timestamp e resultado
* Reinvocação: `LOGIN_SSO`
* JIT provisioning gera evento `USER_JIT_PROVISIONED`
* Falhas (`nonce mismatch`, domain mismatch, etc.) também são registradas