---
title: "Organizações"
description: "Modele a organização, a unidade organizacional, o projeto e os limites de aprovação de acesso."
locale: "pt-BR"
---

> Documentation Index
> Fetch the relevant documentation index at: https://xid.dev/pt-br/llms.txt
> Use this file to discover all available pages before exploring further.

# Organizações

## Hierarquia organizacional

Uma instância contém organizações de nível superior. Uma Organização pode conter um nível de SubOrg; cada organização continua sendo uma política, associação, marca, RBAC e limite de isolamento.

Uma OrgUnit é um departamento ou equipe dentro de uma organização. Ele nunca altera o TenantContext, o emissor, as declarações de token ou o limite de SubOrg de um nível.

- As árvores OrgUnit suportam uma profundidade máxima de oito.
- Cada membro pode ter uma unidade organizacional principal e canais adicionais.
- O gerente ativo mais próximo na cadeia ancestral da unidade organizacional é o primeiro candidato a aprovador de solicitação de acesso.

## Projetos e política de acesso

Os projetos agrupam aplicativos e funções de autorização. A `access_policy` por projeto controla apenas usuários da mesma organização sem um UserGrant efetivo; a autorização ProjectGrant entre organizações não é afetada.

| Política do projeto | Comportamento da mesma organização | Caminho de autoatendimento |
| --- | --- | --- |
| Abrir | Permitido sem UserGrant. | Nenhuma solicitação de acesso é necessária. |
| Restrito | Negado; um administrador concede acesso diretamente. | Nenhuma solicitação de autoatendimento está disponível. |
| Aprovação necessária | Negado até que um AccessRequest seja aprovado. | O usuário envia uma solicitação de acesso. |

## Ciclo de vida da solicitação de acesso

AccessRequest passa de `pendente` para `aprovado`, `negado`, `cancelado` ou `expirado`. Cada resultado é terminal e as solicitações pendentes expiram lentamente após 14 dias.

A aprovação cria um UserGrant rastreável na mesma transação. O solicitante não pode aprovar sua própria solicitação; a resolução passa do gerente da unidade organizacional para os gerentes de projeto e da organização.

| Método | Caminho | Finalidade | Escopo necessário |
| --- | --- | --- | --- |
| `GET, POST` | `/auth/access-requests` | Crie e liste as solicitações do usuário atual. | `session` |
| `POST` | `/auth/access-requests/:id/cancel` | Cancele a solicitação pendente do usuário atual. | `session` |
| `GET` | `/auth/access-approvals` | Lista solicitações que aguardam a aprovação do usuário atual. | `session` |
| `POST` | `/auth/access-approvals/:id/{approve\|deny}` | Aprove ou negue uma solicitação pendente atribuída ao usuário atual. | `session` |
| `GET` | `/v1/organizations/:orgId/access-requests` | Liste solicitações dentro de uma organização. | `access-requests:read` |
| `GET` | `/v1/organizations/:orgId/units` | Leia a árvore da unidade organizacional. | `org-units:read` |
| `POST, PATCH, DELETE, PUT` | `/v1/organizations/:orgId/units/*` | Crie, atualize, mova, arquive e gerencie membros de unidades. | `org-units:write` |

## Limites de segurança

- Cada consulta OrgUnit e AccessRequest tem como escopo `tenant_id` e `org_id`. Identificadores entre organizações ou entre locatários retornam 404 sem revelar a existência.
- A associação e o acesso ao projeto são separados: os convites ingressam em uma organização, enquanto o AccessRequest concede a um membro ativo existente acesso a um projeto.
- O SCIM provisiona usuários e associações, mas não mapeia grupos de diretórios para unidades organizacionais ou funções de projeto na implementação atual.
- A API de gerenciamento usa paginação de cursor e chaves de API compartilhadas ou proteções do gerenciador da organização. Ele não reutiliza rotas comerciais do usuário final.

Source: https://xid.dev/pt-br/organizations/index.mdx