- Impressão
Explorando o OAuth2.0
Bem-vindo a uma exploração do OAuth2.0, um protocolo de autenticação poderoso, mas muitas vezes incompreendido, dentro do universo Tulip. Neste artigo, vamos desvendar os fundamentos, guiá-lo pelos fluxos de autenticação suportados pela Tulip, desmistificar a configuração do seu conector inicial e compartilhar dicas rápidas para um início perfeito.
O OAuth2.0 pode ser complexo e, para manter as coisas concisas, omitimos alguns aspectos técnicos detalhados neste artigo. Se você quiser se aprofundar no manuseio de tokens de atualização, gerenciamento de escopo e público-alvo e configurações de conector personalizadas da Tulip, recomendamos consultar este guia técnico detalhado do OAuth2.0.
Tipos de autenticação
A Tulip suporta três tipos de autenticação OAuth2.0: OAuth2.0 (conta de serviço), OAuth2.0 (credenciais de usuário) e OAuth2.0 (credenciais de cliente). A principal distinção está em como as credenciais são compartilhadas entre os usuários e o fluxo que é executado em relação à especificação OAuth. Uma lista completa e uma descrição dos fluxos exclusivos do OAuth estão disponíveis aqui: https://frontegg.com/blog/oauth-flows.
In older Tulip versions, OAuth2.0 (Service Account) was called OAuth2 (Admin), and OAuth2.0 (User Credentials) was called OAuth2 (Operator).
Fluxo do código de autorização:
- OAuth2.0 (conta de serviço): Usa as credenciais fornecidas durante o teste do conector para todos os usuários no Tulip Player. Ideal para credenciais compartilhadas em sua organização. A reautenticação do administrador é necessária se as credenciais expirarem.
- OAuth2.0 (Credenciais do usuário): Segmenta a autenticação com base no usuário conectado ao Tulip Player. Se um usuário não se autenticou ou se a autenticação expirou, o usuário passa pelo fluxo OAuth dentro do Tulip Player.
Fluxo de credenciais do cliente:
- OAuth2.0 (Credenciais do cliente): Esse tipo de concessão é usado pela Tulip para obter um token de acesso por meio de autenticação com o servidor de autorização usando as credenciais do cliente (ID do cliente e segredo do cliente), normalmente para acessar recursos em seu próprio nome e não em nome de um usuário.
Revelando os conceitos básicos
Antes de se aprofundar nos detalhes, sugerimos que você se familiarize com os Ambientes e obtenha uma visão geral dos Hosts de Conector e suas funções.
O OAuth2.0 serve como um mecanismo para a Tulip (o cliente) estabelecer sua identidade com seus sistemas de negócios.
Fluxo do código de autorização
:::(Aviso) (Aviso) Para concluir o processo de autenticação do usuário, seu navegador precisa permitir pop-ups. Se o seu conector estiver configurado com vários ambientes, cada ambiente abrirá uma janela pop-up separada durante a autenticação.
Como verificar se os pop-ups estão ativados no Chrome:
- Abra o Chrome e clique no menu de três pontos no canto superior direito da janela.
- Selecione Configurações no menu suspenso.
- Role a tela para baixo e clique em Privacidade e segurança.
- Na seção "Privacidade e segurança", clique em Configurações do site.
- Role a tela para baixo e clique em Pop-ups e redirecionamentos.
- Certifique-se de que o botão de alternância esteja definido para permitir pop-ups ou adicione manualmente o site à lista de sites autorizados a exibir pop-ups.
Se os pop-ups estiverem bloqueados, o Chrome exibirá um pequeno ícone na barra de endereços sempre que um pop-up for bloqueado. Você pode clicar nesse ícone para permitir rapidamente os pop-ups da Tulip.
:::
O acesso é concedido por meio de um handshake e a Tulip suporta principalmente o fluxo de código de autorização, o fluxo OAuth mais comum. Aqui está uma visão geral condensada de como esse fluxo se desenvolve:
- O usuário inicia o fluxo clicando no botão Testar antes de salvar um Conector.
- A Tulip se comunica com o servidor de autorização do seu provedor OAuth, compartilhando parâmetros específicos, como identidade do cliente, escopos (o que você está tentando acessar) e outros detalhes relevantes.
- O servidor de autorização solicita que o usuário conceda acesso, conforme exemplificado abaixo:
- Com o consentimento do usuário, o servidor de autorização gera um código de autorização e conclui a janela de autenticação.
- Munida de um código de autorização, a Tulip solicita com segurança um token entrando em contato com o ponto de extremidade do token, fornecendo o código de autorização, o ID do cliente, o segredo do cliente e propriedades adicionais.
- Após validar o código de autorização, o servidor responde com um token e, opcionalmente, um token de atualização. Esse token serve para solicitações autorizadas pelo usuário.
- O Tulip agora pode executar solicitações em nome dos usuários, com o token fornecido para autorização.
Veja os diagramas abaixo para entender o caminho da execução:
Fluxo de credenciais do cliente
O fluxo de credenciais do cliente é usado principalmente para a interação de dois sistemas comerciais. Esse fluxo é configurado uma vez e depois compartilhado por todos os usuários.
- O usuário inicia o fluxo clicando no botão Testar antes de salvar um Conector.
- A Tulip se comunica com o servidor de autorização do seu provedor OAuth, compartilhando parâmetros específicos, como identidade do cliente, escopos (o que você está tentando acessar) e outros detalhes relevantes.
- O servidor de autorização retorna um token de acesso, presumindo que o ID do cliente e o segredo do cliente estejam corretos. Opcionalmente, um token de atualização também pode ser retornado. Esse token serve para solicitações autorizadas pelo usuário.
- A Tulip agora pode executar solicitações em nome dos usuários, com o token fornecido para autorização.
Configuração do OAuth
The Authorize and Token endpoints must be accessible to the cloud for Tulip to execute authentication for connectors.
URL do código de autorização
Esse é o URL que a Tulip contata na etapa 2 do fluxo do código de autenticação. Encontrado na documentação da API do seu provedor OAuth, geralmente termina em /auth
ou /authorize
.
Observação: esse campo não está presente para Credenciais de Cliente.
URL do token de acesso
Após a resposta do servidor de autorização, é feita uma solicitação ao URL do token de acesso para obter um token para autenticação. Geralmente termina em /token
.
Observação: esse campo não está presente nas Credenciais do Cliente.
ID do cliente e segredo do cliente
Gerada a partir da interface do usuário do seu provedor OAuth, a ID do cliente é passada com a solicitação inicial de um código de autorização. A ID do cliente e o segredo do cliente acompanham todas as solicitações de token.
Tempo de expiração padrão (segundos)
Esse campo especifica o tempo padrão (em segundos) após o qual os tokens serão atualizados se nenhum tempo de expiração for explicitamente fornecido ou definido por meio de outro mecanismo fora do campo expires_in
.
Público e escopo
O público especifica os ativos específicos aos quais o usuário busca acesso, enquanto o escopo define as ações desejadas nesses ativos. Ambos são transmitidos durante a solicitação do código de autorização na etapa 2.
Opções adicionais
- Send token request data as JSON (Enviar dados de solicitação de token como JSON): altera o tipo de codificação da solicitação enviada ao URL do token. Ative se necessário para integrações específicas.
- Send Authentication Header for refresh request (Enviar cabeçalho de autenticação para solicitação de atualização): Adiciona um cabeçalho extra às solicitações de atualização quando ativado.
- Ignorar prompt de consentimento do usuário: Controla o atributo prompt da solicitação do código de autenticação. Desativado define-o como
consentimento
, enquanto ativado define-o comologin
, permitindo que o provedor OAuth decida sobre a tela de login a ser exibida.
For some integrations, exclude or set the prompt attribute to none
. Reach out to support@tulip.co for further functionality.
Aprofundando
Deseja obter mais informações? Explore estes artigos: