> ## Documentation Index > Fetch the complete documentation index at: https://docs.play2sell.com/llms.txt > Use this file to discover all available pages before exploring further. # SSO (Single Sign-On) > Os usuários da sua empresa entram no SalesOS sem senha do SalesOS — pelo provedor de login que vocês já usam (OAuth 2.0 / OpenID Connect) — em qualquer página, e voltam por ele quando a sessão vence. # SSO (Single Sign-On) Os usuários da sua empresa podem entrar no SalesOS **sem uma senha do SalesOS**: quem autentica é o provedor de login que a sua empresa já usa. O SalesOS recebe a identidade, confere se a pessoa pertence à sua empresa e abre a sessão. Vale para **o SalesOS inteiro** — tela inicial, leads, carteira, campanhas, ranking — e o link pode levar a pessoa direto a qualquer uma dessas páginas. Este guia é para **quem administra o provedor de login da sua empresa** (a equipe de TI). ## Quem faz o quê | Etapa | Quem | | - | - | | Cadastrar a Play2sell como aplicação no seu provedor e nos enviar os dados | Sua empresa | | Ligar o seu provedor ao SalesOS e devolver o nome da conexão e o link de entrada | Play2sell | | Testar em staging com um usuário de teste | Sua empresa, com a Play2sell | | Repetir em produção e divulgar o link aos usuários | Sua empresa | ## Antes de começar * Acesso de **administrador** ao seu provedor de login (OAuth 2.0 / OpenID Connect). * A sua empresa já usa o SalesOS e o acesso por SSO foi combinado com a Play2sell. * Um usuário de teste no seu provedor que **não seja administrador**: administradores costumam ter acesso automático a tudo, e o teste passaria sem provar nada. ## O que o seu provedor precisa ter | Requisito | Detalhe | | - | - | | Fluxo | *Authorization code* com aplicação **confidencial** (com client secret) | | PKCE | Aceitar PKCE com `S256` em toda autorização | | Endpoint de **userinfo** | **Obrigatório.** A cada login o SalesOS lê o perfil do usuário nele, com o token de acesso | | Identificador estável | Um campo que identifica a pessoa e não muda (veja [O identificador estável](#o-identificador-estável)) | | **E-mail** | **Obrigatório** no perfil. Sem e-mail o login é recusado | | Nome | Recomendado | | Scopes | `openid profile email` (mais os que o seu provedor exigir) | Se o seu provedor permite escolher como a aplicação se autentica no endpoint de token, habilite `client_secret_post` e `client_secret_basic`. ## Passo a passo Crie **uma aplicação por ambiente** (produção e staging) com estes dados: | Item | Produção | Staging | | - | - | - | | Endereço de retorno (redirect URI) | `https://auth.play2sell.com/login/callback` | `https://auth-staging.play2sell.com/login/callback` | | Configuração da aplicação cliente | Aplicação confidencial, com client secret, no fluxo *authorization code* | Igual | | Scopes | `openid profile email` | Igual | **Pronto quando:** as duas aplicações existem e o endereço de retorno de cada uma está exatamente como acima, sem barra no fim. Garanta que o **userinfo** devolve o identificador estável, o **e-mail** e o nome do usuário. Anote o nome de cada campo (ex.: `sub`, `email`, `name`, ou `dados.cpf`). **Pronto quando:** o usuário de teste tem os três campos preenchidos no perfil. No seu provedor, atribua à aplicação os usuários ou grupos que podem entrar no SalesOS. É o passo que mais se esquece: sem a atribuição, o seu provedor recusa o login antes de ele chegar ao SalesOS. **Pronto quando:** o usuário de teste está atribuído às duas aplicações. Nunca por e-mail ou chat em texto. Para cada ambiente: * o caminho da configuração do OpenID Connect (`/.well-known/openid-configuration`) ou os endereços de **autorização**, de **token** e de **userinfo** do seu provedor; * o **client ID** e o **client secret**; * o nome dos campos do **identificador estável**, do **e-mail** e do **nome**; * o usuário de teste e um contato técnico. **Pronto quando:** a Play2sell confirma o recebimento. A Play2sell liga o seu provedor ao SalesOS em staging e devolve o **nome da conexão** e o **link de entrada** (veja [Link de entrada](#link-de-entrada)). Com o usuário de teste (não administrador), abra o link de entrada de staging: | Teste | Resultado esperado | | - | - | | Primeiro acesso, sem `next` | Faz login no seu provedor e cai na tela inicial do SalesOS, já na sua empresa | | Abrir o link de novo, logado no seu provedor | Entra sem digitar nada | | Link com `next` de uma página do SalesOS (ex.: `next=%2Fleads`) | Cai direto nessa página | **Pronto quando:** os três resultados acontecem. Se algo falhar, veja [Solução de problemas](#solução-de-problemas). Repita o passo 4 com os dados da aplicação de produção. Depois da confirmação da Play2sell, divulgue o link de entrada de produção aos usuários — no portal, na intranet ou em qualquer sistema da sua empresa que leve ao SalesOS. ## Link de entrada | Ambiente | Link | | - | - | | Produção | `https://app.play2sell.com/login/sso?connection=&next=` | | Staging | `https://app-staging.play2sell.com/login/sso?connection=&next=` | Cada ambiente tem a sua conexão: o nome de `connection` em staging é o que a Play2sell informa para a aplicação de staging. | Parâmetro | Obrigatório | O que é | | - | - | - | | `connection` | Sim | O nome da conexão da sua empresa, que a Play2sell informa ao ativar | | `next` | Não | A página do SalesOS onde o usuário cai depois de entrar — qualquer página, ex.: `/leads`, `/wallet`, `/ranking`, `/campanha`. Sem ele, abre a tela inicial | Algumas APIs do SalesOS já devolvem o link de entrada pronto para a página certa. A [API de Campanhas](/pt/api/integrations/campaigns#entrar-de-novo-pelo-provedor-da-sua-empresa), por exemplo, traz `access.login_url` com o endereço de cada ambiente — use-o em vez de montar o link no seu código. ### O que acontece quando o usuário abre o link | Situação do usuário | Resultado | | - | - | | Já tem sessão no SalesOS | Abre a página pedida direto | | Sessão do SalesOS vencida, mas logado no seu provedor | Passa pelo seu provedor sem digitar nada e cai na página | | Sem sessão em lugar nenhum | Faz login no **seu** provedor e cai na página | Quem entrou por esse caminho e tem a sessão vencida **dentro** do SalesOS volta pelo seu provedor automaticamente, para a mesma página, em vez de cair numa tela de senha que ele não tem. `next` só aceita um **caminho dentro do SalesOS** (começando com `/`). URL completa, outro host ou caminho de login são ignorados, e o usuário cai na tela inicial. ## O identificador estável É o campo que diz **quem é a pessoa** de um login para o outro. Ele não pode mudar quando o usuário troca de e-mail. A sua empresa escolhe um destes: | Identificador | Quando usar | | - | - | | **Id interno do seu provedor** | O padrão (em geral o campo `sub`) | | **CPF ou CNPJ** | Recomendado quando o seu provedor tem o documento: no primeiro acesso, o SalesOS acha a pessoa que já está cadastrada com esse documento, mesmo que o e-mail seja outro, e o documento passa a constar do cadastro. Aceito com ou sem máscara (11 ou 14 dígitos, com dígito verificador válido); documento inválido é recusado | | **E-mail** | Só quando não há outro; trocar de e-mail no seu provedor equivale a ser outra pessoa | Campos com namespace (ex.: `https://suaempresa.com/cpf`) e campos aninhados (ex.: `dados.cpf`) são aceitos. ## Quem entra e quem é recusado O login pelo provedor da sua empresa **não abre a conta de quem não é da sua empresa**. Usuário novo entra já vinculado à sua empresa, com o cargo padrão combinado com a Play2sell; mudanças de cargo são feitas no SalesOS. Os casos abaixo são recusados, cada um com uma mensagem que diz ao usuário o que fazer: | Situação | O que o usuário vê | | - | - | | O e-mail já tem conta no SalesOS ligada a **outra empresa** | "Este e-mail já tem uma conta no SalesOS" — entrar com o login do SalesOS | | É uma conta da **equipe Play2sell** | "Use o login do SalesOS" | | O acesso da pessoa na sua empresa foi **desativado** no SalesOS | "Seu acesso está desativado" — falar com o gestor | | O acesso da sua empresa por este caminho está **desligado** | "Este acesso está desligado" | | A conexão usada **não está liberada** no SalesOS | "Este acesso não está liberado" | | O seu provedor não enviou o **e-mail** | "O login da sua empresa não enviou o seu e-mail" | | O seu provedor não enviou o **identificador** | "O login da sua empresa não enviou a sua identificação" | | O **CPF/CNPJ** enviado não é válido | "O CPF ou CNPJ enviado não é válido" | | O **userinfo** do seu provedor não respondeu | "O login da sua empresa não respondeu como esperado" | ## Desligamento e troca do client secret * **Quem sai da sua empresa:** desative a pessoa no seu provedor. O próximo login dela é recusado pelo seu provedor; a sessão que ela já tinha aberta no SalesOS vale até vencer. Para cortar também no SalesOS, peça ao gestor da sua empresa no SalesOS para desativar o acesso dela. * **Troca do client secret:** muitos provedores fazem o secret vencer (em geral entre 6 e 24 meses). Antes do vencimento, gere um novo e envie à Play2sell pelo mesmo canal seguro, com a data para a troca, para o login não parar. ## Solução de problemas | Sintoma | Causa provável | O que fazer | | - | - | - | | O seu provedor mostra erro de endereço de retorno | O redirect URI não é exatamente o da tabela do passo 1 | Corrija o endereço, sem barra no fim, no ambiente certo | | O seu provedor diz que o usuário não tem acesso à aplicação | O usuário não foi atribuído à aplicação | Atribua o usuário ou o grupo (passo 3) | | "O login da sua empresa não enviou o seu e-mail" | O e-mail não está no userinfo, ou o campo informado é outro | Libere o e-mail no perfil e confira o nome do campo | | "O login da sua empresa não respondeu como esperado" | O userinfo devolveu erro ou não respondeu | Confira se o userinfo aceita o token de acesso da aplicação | | O login funcionava e parou para todos | Client secret vencido | Gere um novo e envie à Play2sell | Ao pedir ajuda à Play2sell, envie: o **horário** da tentativa, o **e-mail** do usuário, o **ambiente** (produção ou staging) e o **código ou texto** do erro que apareceu na tela. ## Segurança * **Código de autorização com troca servidor a servidor:** nenhum token de identidade passa pela URL do navegador. * **PKCE** em toda autorização. * O **client secret** fica só no serviço de autenticação da Play2sell; não é guardado no banco do SalesOS nem aparece de volta em tela nenhuma. * **Negado por padrão:** um login por uma conexão que não está liberada, ou de uma empresa com o acesso desligado, é recusado — nunca cai num caminho alternativo. ## Próximos passos Exemplo de API que devolve o link de entrada pronto (`access.login_url`) Integrações servidor a servidor This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.