## Contexto Comecei a desenvolver o Logto porque notei que a Gestão de Identidade e Acessos (IAM) tinha-se tornado cada vez mais complexa e ampla ao longo do tempo. O conceito de IAM é tão amplo que gerou novos conceitos, como WIAM (Workforce IAM) e CIAM (Customer IAM). Embora WIAM e CIAM compartilhem a mesma base, eles possuem casos de uso distintos: WIAM é tipicamente usado para utilizadores internos, enquanto CIAM é usado para clientes externos. Alguns exemplos: - **WIAM** A tua empresa tem um sistema de identidade unificado para funcionários, assim todos podem usar a mesma conta para aceder a recursos da empresa, como assinaturas de software, serviços de computação em nuvem, etc. - **CIAM** A tua livraria online requer um sistema de identidade para clientes e vendedores. A experiência de início de sessão é uma parte crítica da integração, pois está localizada no topo do funil de conversão. Logto começou com o CIAM por vários motivos (teremos outro artigo a falar sobre isso). Durante o desenvolvimento, percebemos que construir uma compreensão unificada entre a equipa seria benéfico antes de levar nosso produto ao próximo nível. Esperamos que isso também te ajude a obter uma melhor compreensão do panorama do IAM. Vamos começar! ## O básico do CIAM Independentemente das suas diferenças, WIAM e CIAM têm a mesma base: autenticação e autorização. Estes dois conceitos estão no núcleo das suas funcionalidades. Neste artigo, vamos nos concentrar nos conceitos fundamentais do CIAM e nos problemas que podemos encontrar durante ou após o fluxo de autenticação. Também discutiremos o single sign-on (SSO) e seus cenários relacionados. ### Autenticação e autorização - Autenticação (AuthN) responde à pergunta "Qual identidade possuis?" - Autorização (AuthZ) responde à pergunta "O que podes fazer?" > 💡 Autenticação é inicialmente definida como "Quem és tu?". No entanto, ao discutir identidades digitais, é mais preciso demonstrar a autenticação como "provar a posse da identidade". (Crédito para [Calm-Card-2424](https://www.reddit.com/r/programming/comments/10uycg0/comment/j7eyhrb/)) Se descobrires algo que não se encaixa em nenhuma dessas duas categorias, provavelmente não é essencial para o negócio de identidade. - **Exemplos para autenticação** - Início de sessão com palavra-passe, início de sessão sem palavra-passe, início de sessão social, etc. - Autenticação Máquina-a-Máquina - **Exemplos para autorização** - Controle de Acesso Baseado em Funções - Controle de Acesso Baseado em Atributos - **Exemplos para exceções** - Dados que não são de identidade - Web hooks ### Identidade e Inquilino A identidade geralmente representa um utilizador ou uma máquina. Após uma autenticação bem-sucedida, um Token de ID é emitido como Identidade. Em outras palavras, o principal objetivo da autenticação é obter uma Identidade. Um Inquilino é um grupo de identidades: ```mermaid graph TD Tenant --- A[Identidade: Utilizador 1] Tenant --- B[Identidade: Utilizador 2] Tenant --- C[Identidade: Máquina 1] ``` Quando discutimos "Multi-tenant", estamos nos referindo a múltiplas instâncias de Logto que são isoladas umas das outras em termos de identidade. Em outras palavras, múltiplas instâncias do Logto. ```mermaid graph TD T1[Inquilino 1] --- A[Identidade: Utilizador 1] T2[Inquilino 2] --- B[Identidade: Utilizador 1] T2[Inquilino 2] --- C[Identidade: Máquina 1] subgraph IS2[Sistema de Identidade 2] T2 B C end subgraph IS1[Sistema de Identidade 1] T1 A end ``` Note que há dois sistemas de identidade **isolados**, ou seja, não podes usar a Identidade do Inquilino 1 no Inquilino 2, mesmo para o mesmo identificador (email, telefone, etc.). É como se a tua associação ao Costco não fosse válida no Whole Foods. 🧱 Em suma, existem "paredes físicas" entre os Inquilinos. A definição de "Inquilino" varia entre produtos CIAM. Alguns referem-se ao termo "Organização" em Logto, que será introduzido mais tarde. ### Aplicação e Inquilino Assim como a Identidade, uma Aplicação também pertence a um Inquilino. Várias coisas a lembrar: - Tipicamente, não há relação direta entre uma Aplicação e uma Identidade. - Uma Identidade pode representar uma Aplicação, mas não há conexão direta entre elas. - Assim como utilizadores, aplicações também são a nível de Inquilino. - Aplicações são código, enquanto utilizadores são humanos. - O único propósito das Aplicações é concluir a autenticação, ou seja, obter uma Identidade. ### Provedor de Identidade (IdP) e Provedor de Serviço (SP) A diferença entre esses dois provedores é complicada mas importante. - **Provedor de Identidade** é um serviço que fornece autenticação (AuthN) e emite identidades. Podes encontrar várias explicações sobre Provedor de Serviço no Google, embora possam não ser satisfatórias. Na minha opinião, Provedor de Serviço é um conceito relativo: - **Provedor de Serviço (ou Parte Confiável em [OIDC](https://openid.net/specs/openid-connect-core-1_0.html))** é um serviço ou cliente que inicia a autenticação (AuthN) e solicita o resultado aos Provedores de Identidade. #### Quiz Considera um cenário típico de início de sessão social: ```mermaid graph LR A[App iOS] --> |Iniciar início de sessão| Logto --> |Redirecionar| GitHub GitHub --> |Retornar ID GitHub| Logto --> |Retornar ID Logto| A ``` **❓ Quantos Provedores de Serviço e Provedores de Identidade há neste gráfico?**

Resposta

Ambos têm dois. App iOS é um provedor de serviço para Logto, enquanto Logto é um provedor de identidade. Logto também é um provedor de serviço para GitHub, enquanto GitHub é um provedor de identidade. Assim, Logto é um Provedor de Serviço e também um Provedor de Identidade.

## Estudo de caso: Uma empresa de soluções tecnológicas És um CTO de uma empresa de soluções tecnológicas, tens mais de 100 parceiros comerciais e entregaste mais de 300 projetos. - Cada projeto é ou um aplicativo web ou um aplicativo móvel com um serviço backend. - Para cada parceiro comercial, queres refatorar o sistema de utilizadores para fornecer SSO através dos seus projetos. **❓ Como o Logto (ou um produto CIAM) pode ajudar?**

Resposta

Cria uma instância do Logto para cada parceiro comercial. Cada parceiro mantém um Inquilino. Os projetos são mapeados para "Aplicações" no Logto. ```mermaid graph TD T1[Inquilino 1] --- A[Aplicação 1] T1 --- B[Aplicação 2] T1 --- C[Aplicação 3] T1 --- U1[Utilizador 1] T1 --- U2[Utilizador 2] T2[Inquilino 2] --- D[Aplicação 1] T2 --- E[Aplicação 2] T2 --- U21[Utilizador 1] T2 --- U22[Utilizador 2] ``` Logto oferece uma experiência de início de sessão universal (ou seja, SSO) dentro de um Inquilino, para que os utilizadores não precisem iniciar sessão novamente ao aceder a outra aplicação no mesmo Inquilino, se já tiverem iniciado sessão.

## O que falamos quando falamos sobre SSO Descobrimos que o termo “SSO” muitas vezes causa confusão. Consideramos o single sign-on (SSO) como um comportamento, não um conceito de negócio. Portanto, SSO não é equivalente a “SSO em WIAM”. Quando dizemos “precisa de SSO”, isso pode referir-se a um dos seguintes casos: ### Caso SSO 1 > 👉🏽 Numa grande corporação, os funcionários usam as mesmas credenciais para iniciar sessão em todos os recursos licenciados pela empresa (por exemplo, email, IM, serviços de nuvem). É o cenário típico de WIAM. Neste caso, está envolvido um único Provedor de Identidade. Não nos preocupamos por agora. ### Caso SSO 2 > 👉🏽 Utilizadores finais usam as mesmas credenciais para iniciar sessão em todos os serviços desenvolvidos pela mesma empresa (por exemplo, GSuite). Logto está atualmente focado na abordagem delineada acima. Múltiplos provedores de identidade externos, como um provedor de início de sessão social de terceiros, podem existir de forma independente e sem conexão. Apesar disso, Logto permanece como a única fonte de verdade para Identidades, simplesmente "emprestando"-as de outros provedores. Neste caso, Logto atua tanto como um Provedor de Identidade (para aplicativos GSuite) quanto como um Provedor de Serviço (para Provedores de Identidade externos). ### Caso SSO 3 > 👉🏽 Utilizadores finais só podem usar o Provedor de Identidade específico dentro do domínio de email correspondente para concluir a autenticação. Por exemplo, iniciar sessão no Figma com o Google Workspace. Este é o caso de uso mais comum para SSO em CIAM. Vamos dar uma olhada mais de perto. Se quisermos iniciar sessão no Figma usando nosso email @silverhand.io, podemos usar tanto o início de sessão social quanto o SSO. As ilustrações abaixo mostram a diferença entre os dois:

Em palavras: - Após o início de sessão social, os utilizadores são livres para definir uma palavra-passe ou alterar o endereço de email no Figma - Após o SSO, os utilizadores não conseguem definir palavra-passe ou alterar qualquer informação pessoal, incluindo endereço de email, uma vez que suas Identidades são geridas pelo Google Workspace Neste caso, Logto é tanto um Provedor de Identidade quanto um Provedor de Serviço. Parece que o SSO é mais complexo do que um processo normal de início de sessão. Quais são os benefícios para o proprietário da identidade? - **Controle centralizado:** Manter informações de identidade e processos de autenticação num único local, e garantir que a informação dos utilizadores esteja sempre atualizada. Não há necessidade de adicionar e remover licenças entre diferentes aplicações para alterações. - **Melhor experiência do utilizador:** Os proprietários de identidades que requerem SSO são geralmente corporações. Seus funcionários podem usar as mesmas credenciais e sessão compartilhada para aplicações entre empresas, como Figma, Zoom, Slack, etc. - **Segurança melhorada:** Podes ter notado que algumas corporações exigem métodos de início de sessão específicos, como códigos de verificação dinâmicos. Usar SSO pode garantir que todos os funcionários usem a mesma combinação de métodos de início de sessão para acessar todos os recursos. > 🤔 Inteligente como tu deves ter notado que este é na verdade o **Caso SSO 1** do ponto de vista do SaaS. É hora de discutir o "X" no gráfico do SSO. Isto representa o processo de conexão do domínio de email do Figma a um Provedor de Identidade específico. Mas como funciona? ## Mapeamento de SSO Uma vez que o pedido geralmente vem de clientes empresariais, referimos ao processo de "Caso SSO 3" da seção anterior como "SSO Empresarial" por clareza. Podemos facilmente conceber uma solução ingênua: criar um mapeamento entre domínios de email e métodos de SSO e, em seguida, atualizá-lo manualmente. A ação do processo “X” agora é clara: > 🔍 **Encontrar o método de SSO Empresarial mapeado para o domínio de email fornecido** Assim, se configurares `silverhand.io` como um domínio de email válido que se conecta com um URL de SSO do Google Workspace, os utilizadores que tentarem iniciar sessão com um email `@silverhand.io` serão redirecionados para a página de início de sessão correspondente ao Google Workspace, em vez de serem processados in-place. Quando tens apenas algumas dezenas de clientes que necessitam de SSO Empresarial, gerir o mapeamento manualmente é viável. No entanto, há mais considerações a ter em conta: 1. _O que acontece se houver centenas ou milhares de clientes de SSO Empresarial?_ 2. _Qual é a relação entre "utilizadores comuns" e "utilizadores de SSO Empresarial"?_ 3. _Os dados devem ser isolados entre diferentes clientes de SSO Empresarial?_ 4. _É necessário fornecer um painel de controle para os administradores de SSO Empresarial visualizarem utilizadores ativos, logs de auditoria, etc.?_ 5. _Como as contas podem ser automaticamente desativadas quando um utilizador é removido do Provedor de Identidade de SSO Empresarial?_ E muito mais. Uma vez que quase todos os SSO Empresariais são baseados em domínio de email, podemos rapidamente formular uma solução melhor: - Se o utilizador pode provar a posse desse domínio, ele pode configurar o SSO empresarial desse domínio de forma auto-servida. Esta solução aborda as duas primeiras questões: > _1. O que fazer se houver centenas ou milhares de clientes de SSO Empresarial?_ - Eles podem configurar o SSO Empresarial de forma auto-servida. > _2. Qual é a relação entre "utilizadores comuns" e "utilizadores de SSO Empresarial"?_ - Abrimos todos os métodos de início de sessão possíveis para utilizadores comuns, exceto o SSO Empresarial; Enquanto limitamos o método de início de sessão apenas ao SSO Empresarial para os utilizadores que estão tentando iniciar sessão com os domínios configurados. Quanto à terceira questão: > _3. Os dados devem ser isolados entre diferentes clientes de SSO Empresarial?_ - Sim e não. É hora de introduzir a organização. ## Organização Mencionamos usar domínios de email para reconhecer o método de SSO Empresarial específico a ser usado; em outras palavras, aplicando um tratamento específico para um lote específico de utilizadores. No entanto, os requisitos do cliente são frequentemente mais do que apenas SSO Empresarial; por exemplo, questões 4 e 5 na seção anterior. Ao longo dos anos, foi desenvolvido um modelo maduro por empresas de SaaS de destaque para abordar esses tipos de problemas: Organizações. **Regras das Organizações** 1. Uma organização é um grupo de identidades, tipicamente menor que um Inquilino. 2. Todas as organizações estão associadas a um Inquilino. Podes ver outros termos, como "Workspace", “Equipe”, ou até mesmo "Inquilino" no software. Para identificar se é o conceito que estamos discutindo, basta verificar se representa “um grupo de Identidades”. Neste artigo, usaremos o termo "Organização" para consistência. 🤹🏽‍♀️ Na maioria dos casos, "um grupo de Identidades" é equivalente a "um grupo de utilizadores". No entanto, **a mesma Identidade pode existir em múltiplas Organizações**. No Notion, podes criar e entrar em múltiplos workspaces (ou seja, Organizações) com o mesmo endereço de email e alternar entre eles facilmente. No Slack, parece ser o mesmo, mas suspeitamos que utiliza diferentes Identidades nos bastidores, uma vez que precisamos criar uma nova conta para cada workspace.

![Workspaces do Slack](https://uploads.strapi.logto.io/1/slack_workspaces_b4f0bcc978.png) _Workspaces do Slack_ ![Workspaces do Notion](https://uploads.strapi.logto.io/1/notion_workspaces_5bdc2b7e9b.png) _Workspaces do Notion_

No Notion, há um “Plano Pessoal” disponível, que é normalmente uma Organização sob orçamento, com o único utilizador (tu) dentro. Não sabemos a implementação exata do Notion, mas esta explicação é razoável e arquivável para o nosso modelo. Cada Organização também tem um identificador, geralmente referido como o “domínio da Organização”. Um "domínio de Organização" é um identificador interno usado para distinguir Organizações. Pode diferir do "domínio de email", pois o primeiro é gerido pelo Provedor de Serviço, enquanto o último é geralmente fornecido por um Provedor de Identidade externo. Por exemplo, podes usar `foo` como o domínio da Organização no Slack, mas usar `@bar.io` como o domínio de email para esta Organização. ### Quiz **❓ Uma aplicação pode ser associada a uma Organização?**

Resposta

Sim, sim. Como discutimos no início, uma aplicação pode ter uma Identidade. Podes elaborar um cenário de negócio para isto?

## Questões restantes > _3. Os dados devem ser isolados entre diferentes clientes de SSO Empresarial?_ - **Sim:** Isolar dados comerciais, como mensagens e documentos, no nível da Organização. - **Não:** Manter as Identidades independentes, pois não precisam ser associadas a uma Organização. - Note que há três entidades distintas envolvidas aqui: Identidades, Organizações, e configurações de SSO Empresarial; o que aumentou notavelmente a complexidade. A questão em si não é específica o suficiente. > _4. É necessário fornecer um painel de controle para os administradores de SSO Empresarial verem utilizadores ativos, logs de auditoria, etc.?_ > > _5. Como desativar automaticamente contas quando utilizadores são removidos do Provedor de Identidade de SSO Empresarial?_ - Estas demandas são mais orientadas para negócios e podem ser implementadas no nível da Organização. Vamos deixá-las em aberto aqui. ## Notas finais Introduzimos vários conceitos: Autenticação (AuthN), Autorização (AuthZ), Identidade, Inquilino, Aplicação, Provedor de Identidade (IdP), Provedor de Serviço (SP), Single sign-on (SSO), e SSO Empresarial (Organização). Pode levar algum tempo para entendê-los todos. Enquanto escrevia este artigo, notei que, curiosamente, os planos mais caros de serviços online costumam incluir recursos exclusivos relacionados à autorização, que não são mencionados neste artigo. Podes já ter algumas perguntas sobre autorização, como: - Como podemos atribuir permissões a um utilizador e verificá-las? - Qual modelo de autorização devo usar? - Qual é a melhor prática para aplicar um modelo de autorização? 🔥 Faz uma pausa e vê-te em CIAM 102!