- 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.
:::(Info) (Observação) Em versões anteriores do Tulip, o OAuth2.0 (Service Account) era chamado de OAuth2 (Admin) e o OAuth2.0 (User Credentials) era chamado de 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
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, com 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, supondo 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
:::(Warning) (Serviços On-Prem) Os endpoints Authorize e Token devem estar acessíveis à nuvem para que a Tulip execute a autenticação para conectores:
URL do código de autorização
Este é 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.
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
- 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.
:::(Warning) (Observação) Para algumas integrações, exclua ou defina o atributo prompt como nenhum
. Entre em contato com support@tulip.co para obter mais funcionalidades. :::
Aprofundando
Deseja obter mais insights? Explore estes artigos: