## Contexto Comecei a construir o Logto porque notei que o Gerenciamento de Identidade e Acesso (IAM) tornou-se cada vez mais complexo e expansivo ao longo do tempo. O conceito de IAM é grande o suficiente para dar origem a novos conceitos, como WIAM (Workforce IAM) e CIAM (Customer IAM). Embora WIAM e CIAM compartilhem a mesma base, eles têm casos de uso distintos: WIAM é tipicamente usado para usuários internos, enquanto CIAM é usado para clientes externos. Alguns exemplos: - **WIAM** Sua empresa tem um sistema de identidade unificado para os funcionários, assim todos podem usar a mesma conta para acessar recursos da empresa, como assinaturas de software, serviços de computação em nuvem, etc. - **CIAM** Sua livraria online requer um sistema de identidade do usuário para clientes e vendedores. A experiência de login é uma parte crítica da integração, pois está localizada no topo do funil de conversão. O Logto começou com o CIAM por várias razões (teremos outro artigo falando sobre isso). Durante o desenvolvimento, percebemos que seria benéfico construir um entendimento unificado entre a equipe antes de levar nosso produto ao próximo nível. Esperamos que isso também ajude a ter uma melhor compreensão do cenário de IAM. Vamos começar! ## As bases do CIAM Independentemente de suas diferenças, WIAM e CIAM têm a mesma base: autenticação e autorização. Esses dois conceitos estão no cerne de suas funcionalidades. Neste artigo, focaremos 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 você possui?” - Autorização (AuthZ) responde à pergunta “O que você pode fazer?” > 💡 A autenticação é inicialmente definida como "Quem é você?". No entanto, ao discutir identidades digitais, é mais preciso demonstrar a autenticação "provando a posse da identidade". (Crédito a [Calm-Card-2424](https://www.reddit.com/r/programming/comments/10uycg0/comment/j7eyhrb/)) Se você descobrir algo que não se encaixa em nenhuma dessas duas categorias, provavelmente não é essencial para o negócio de identidade. - **Exemplos de autenticação** - Login com senha, login sem senha, login social, etc. - Autenticação Machine-to-Machine - **Exemplos de autorização** - Controle de Acesso Baseado em Funções - Controle de Acesso Baseado em Atributos - **Exemplos de exceções** - Dados não relacionados à identidade - Web hooks ### Identidade e Inquilino Identidade geralmente representa um usuário 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[Identity: User 1] Tenant --- B[Identity: User 2] Tenant --- C[Identity: Machine 1] ``` Quando discutimos "Multi-inquilino", estamos nos referindo a várias instâncias do Logto que são isoladas umas das outras em termos de identidade. Em outras palavras, várias instâncias do Logto. ```mermaid graph TD T1[Tenant 1] --- A[Identity: User 1] T2[Tenant 2] --- B[Identity: User 1] T2[Tenant 2] --- C[Identity: Machine 1] subgraph IS2[Identity system 2] T2 B C end subgraph IS1[Identity system 1] T1 A end ``` Observe que existem dois sistemas de identidade **isolados**, ou seja, você não pode usar a Identidade do Inquilino 1 no Inquilino 2, mesmo que seja o mesmo identificador (email, telefone, etc.). É como sua associação no Costco não ser válida no Whole Foods. 🧱 Em resumo, há “paredes físicas” entre Inquilinos. A definição de "Inquilino" varia entre os produtos CIAM. Alguns se referem ao termo "Organização" em Logto, que será introduzido mais tarde. ### Aplicativo e Inquilino Assim como a Identidade, um Aplicativo também pertence a um Inquilino. Várias coisas a serem lembradas: - Normalmente, não há relação direta entre um Aplicativo e uma Identidade. - Uma Identidade pode representar um Aplicativo, mas não há conexão direta entre eles. - Assim como os usuários, os aplicativos também são de nível de Inquilino. - Aplicativos são código, enquanto usuários são humanos. - O único propósito dos Aplicativos é completar 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. Você pode encontrar várias explicações sobre Provedor de Serviço no Google, embora elas possam não ser satisfatórias. Na minha mente, Provedor de Serviço é um conceito relativo: - **Provedor de Serviço (ou Parte Confiante 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 de Provedores de Identidade. #### Quiz Considere um cenário típico de login social: ```mermaid graph LR A[iOS App] --> |Invoke sign-in| Logto --> |Redirect| GitHub GitHub --> |Return GitHub ID| Logto --> |Return Logto ID| A ``` **❓ Quantos Provedores de Serviço e Provedores de Identidade há neste gráfico?**

Resposta

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

## Estudo de caso: Uma empresa de soluções tecnológicas Você é um CTO de uma empresa de soluções tecnológicas, tem mais de 100 parceiros de negócios e já entregou mais de 300 projetos. - Cada projeto é um aplicativo web ou móvel com um serviço de backend. - Para cada parceiro de negócios, você deseja refatorar o sistema de usuários para fornecer SSO em seus projetos. **❓ Como o Logto (ou um produto CIAM) pode ajudar?**

Resposta

Crie uma instância do Logto para cada parceiro de negócios. Cada parceiro possui um Inquilino. Projetos são mapeados para "Aplicativos" no Logto. ```mermaid graph TD T1[Tenant 1] --- A[App 1] T1 --- B[App 2] T1 --- C[App 3] T1 --- U1[User 1] T1 --- U2[User 2] T2[Tenant 2] --- D[App 1] T2 --- E[App 2] T2 --- U21[User 1] T2 --- U22[User 2] ``` Logto oferece uma experiência de login universal (ou seja, SSO) dentro de um Inquilino, então os usuários não precisam fazer login novamente ao acessar outro aplicativo no mesmo Inquilino se já estiverem logados.

## O que falamos quando falamos de SSO Notamos que o termo “SSO” muitas vezes causa confusão. Consideramos o single sign-on (SSO) um comportamento, não um conceito de negócio. Portanto, SSO não equivale a “SSO no WIAM”. Quando dizemos “é necessário SSO”, pode se referir a um dos seguintes casos: ### Caso de SSO 1 > 👉🏽 Em uma grande corp, os funcionários usam as mesmas credenciais para se conectar a todos os recursos licenciados pela empresa (por exemplo, email, IM, serviços de nuvem). É o cenário típico de WIAM. Nesse caso, apenas um Provedor de Identidade está envolvido. Por enquanto, não nos importamos. ### Caso de SSO 2 > 👉🏽 Usuários finais usam as mesmas credenciais para se conectar a todos os serviços desenvolvidos pela mesma empresa (por exemplo, GSuite). Logto está atualmente focado na abordagem descrita acima. Vários provedores de identidade externos, como um provedor de login social de terceiros, podem existir de forma independente e sem conexão. Apesar disso, o Logto continua sendo a única fonte de verdade para Identidades, simplesmente "pegando emprestado" de outros provedores. Nesse caso, o Logto atua tanto como Provedor de Identidade (para aplicativos GSuite) quanto como Provedor de Serviço (para Provedores de Identidade externos). ### Caso de SSO 3 > 👉🏽 Usuários finais só podem usar o Provedor de Identidade específico dentro do domínio de email correspondente para concluir a autenticação. Por exemplo, fazer login no Figma com o Google Workspace. Este é o caso de uso mais comum para SSO no CIAM. Vamos dar uma olhada mais de perto. Se quisermos fazer login no Figma usando nosso e-mail @silverhand.io, podemos usar login social ou SSO. As figuras abaixo ilustram a diferença entre os dois:

Em palavras: - Após o login social, os usuários são livres para definir uma senha ou alterar o endereço de email no Figma - Após o SSO, os usuários não podem definir senha ou alterar qualquer informação pessoal, incluindo o endereço de email, pois suas Identidades são geridas pelo Google Workspace Nesse caso, o Logto é tanto um Provedor de Identidade quanto um Provedor de Serviço. Parece que o SSO é mais complexo do que um processo de login normal. Quais são os benefícios para o dono da identidade? - **Controle centralizado:** Mantenha as informações de identidade e processos de autenticação em um só lugar e garanta que as informações dos usuários estejam sempre atualizadas. Não há necessidade de adicionar ou remover licenças em diferentes aplicativos para realizar alterações. - **Melhor experiência do usuário:** Donos de identidade que requerem SSO são geralmente corporações. Seus funcionários podem usar as mesmas credenciais e sessão compartilhada para aplicativos entre empresas, como Figma, Zoom, Slack, etc. - **Segurança aprimorada:** Você pode ter notado que algumas corporações exigem métodos de login específicos, como códigos de verificação dinâmicos. Utilizar SSO pode garantir que todos os funcionários usem a mesma combinação de métodos de login para acessar todos os recursos. > 🤔 Inteligente como você deve ter notado que isso é, na verdade, o **Caso de SSO 1** da perspectiva SaaS. É hora de discutir o "X" no gráfico de SSO. Isso representa o processo de conexão do Figma ao domínio de email a um Provedor de Identidade específico. Mas, como funciona? ## Mapeamento de SSO Uma vez que a solicitação frequentemente vem de clientes empresariais, nos referimos ao processo de "Caso de SSO 3" da seção anterior como "SSO Empresarial" para maior clareza. Podemos facilmente elaborar uma solução ingênua: criar um mapeamento entre domínios de email e métodos de SSO, e 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 você configurar `silverhand.io` como um domínio de email válido que se conecta a uma URL de SSO do Google Workspace, os usuários que tentarem fazer login com um email `@silverhand.io` serão redirecionados para a página de login do Google Workspace correspondente, em vez de serem processados localmente. Quando você tem apenas algumas dezenas de clientes que precisam de SSO Empresarial, gerenciar manualmente o mapeamento está razoável. No entanto, há mais coisas a considerar: 1. _E se houver centenas ou milhares de clientes de SSO Empresarial?_ 2. _Qual é a relação entre “usuários normais” e “usuários de SSO Empresarial”?_ 3. _Os dados devem ser isolados entre diferentes clientes de SSO Empresarial?_ 4. _Há necessidade de fornecer um painel de controle para os administradores de SSO Empresarial visualizarem usuários ativos, logs de auditoria, etc.?_ 5. _Como podem ser desativadas automaticamente as contas quando um usuário é removido do Provedor de Identidade do SSO Empresarial?_ E muito mais. Já que quase todos os SSO Empresariais são baseados em domínios de email, podemos rapidamente encontrar uma melhor solução: - Se o usuário puder provar a posse desse domínio, ele pode configurar o SSO empresarial desse domínio de maneira autoatendimento. Esta solução trata as duas primeiras questões: > _1. E se houver centenas ou milhares de clientes de SSO Empresarial?_ - Eles podem configurar o SSO Empresarial de maneira autoatendimento. > _2. Qual é a relação entre “usuários normais” e “usuários de SSO Empresarial”?_ - Disponibilizamos todos os possíveis métodos de login para usuários normais, exceto o SSO Empresarial; Enquanto limitamos o método de login ao SSO Empresarial apenas para os usuários que estão tentando fazer login 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 específico de SSO Empresarial a ser usado; em outras palavras, aplicando um tratamento específico para um lote específico de usuários. No entanto, os requisitos do cliente geralmente são mais do que apenas SSO Empresarial; por exemplo, as perguntas 4 e 5 da seção anterior. Ao longo dos anos, um modelo maduro foi desenvolvido por empresas SaaS notáveis para resolver esses tipos de problemas: Organizações. **Regras de 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. Você pode ver outros termos, como “Workspace”, “Team”, ou até mesmo “Tenant” 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 usuários". No entanto, **a mesma Identidade pode existir em várias Organizações**. No Notion, você pode criar e ingressar em vários espaços de trabalho (ou seja, Organizações) com o mesmo endereço de email e alternar entre eles facilmente. Para o Slack, parece ser o mesmo, mas suspeitamos que ele use Identidades diferentes nos bastidores, pois precisamos criar uma nova conta para cada espaço de trabalho.

![Espaços de trabalho Slack](https://uploads.strapi.logto.io/1/slack_workspaces_b4f0bcc978.png) _Espaços de trabalho Slack_ ![Espaços de trabalho Notion](https://uploads.strapi.logto.io/1/notion_workspaces_5bdc2b7e9b.png) _Espaços de trabalho Notion_

O Notion possui um “Plano Pessoal” disponível, que é normalmente uma Organização internamente, com o único usuário (você) dentro. Não sabemos a implementação exata do Notion, mas essa explicação é razoável e alcançável para nosso modelo. Cada Organização também possui um identificador, geralmente referido como “domínio da Organização”. Um "domínio da Organização" é um identificador interno usado para distinguir Organizações. Ele pode diferir do "domínio de email", já que o primeiro é gerenciado pelo Provedor de Serviço, enquanto o último é geralmente fornecido por um Provedor de Identidade externo. Por exemplo, você pode usar `foo` como domínio de Organização no Slack, mas usar `@bar.io` como domínio de email para esta Organização. ### Quiz **❓ Um aplicativo pode ser associado a uma Organização?**

Resposta

Sim, sim. Como discutimos no início, um aplicativo pode ter uma Identidade. Você pode elaborar um cenário de negócio para isso?

## Questões restantes > _3. Os dados devem ser isolados entre diferentes clientes de SSO Empresarial?_ - **Sim:** Isole dados de negócios, como mensagens e documentos, no nível da Organização. - **Não:** Mantenha as Identidades independentes, já que não precisam ser associadas a uma Organização. - Observe que aqui estão envolvidos três entidades distintas: Identidades, Organizações e configurações de SSO Empresarial; o que aumentou notavelmente a complexidade. A própria pergunta não é suficientemente específica. > _4. Há necessidade de fornecer um painel para os administradores de SSO Empresarial visualizarem usuários ativos, logs de auditoria, etc.?_ > > _5. Como desativar automaticamente a conta quando o usuário é removido 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. Deixaremos abertas aqui. ## Notas finais Introduzimos vários conceitos: Autenticação (AuthN), Autorização (AuthZ), Identidade, Inquilino, Aplicativo, Provedor de Identidade (IdP), Provedor de Serviço (SP), Single sign-on (SSO) e SSO Empresarial (Organização). Pode levar algum tempo para entender todos eles. Ao escrever este artigo, percebi que, curiosamente, os planos mais caros dos serviços online frequentemente incluem recursos exclusivos relacionados à autorização, que são totalmente não mencionados neste artigo. Você já pode ter algumas perguntas sobre autorização, como: - Como podemos atribuir permissões a um usuário e verificá-las? - Qual modelo de autorização devo usar? - Qual é a melhor prática para aplicar um modelo de autorização? 🔥 Faça uma pausa e nos vemos no CIAM 102!