MENU
    Detalhes técnicos e de configuração do OAuth2.0
    • 23 Jan 2025
    • 4 Minutos para Ler
    • Contribuintes

    Detalhes técnicos e de configuração do OAuth2.0


    Resumo do artigo

    Neste artigo, vamos nos aprofundar nos detalhes técnicos de como a Tulip implementa o OAuth para autenticação de conectores. O OAuth é poderoso, mas vem com alguma complexidade adicional. Este guia tem o objetivo de abordar quaisquer questões técnicas sobre o que a Tulip suporta e como ele é integrado.

    Observação: O fluxo de Credenciais do Cliente difere um pouco do fluxo do código de autorização. As etapas 1 e 2 não são relevantes para o fluxo de credenciais do cliente.

    Fluxo do código de autorização da Tulip

    On-Prem Services

    The Authorize and Token endpoints must be accessible to the cloud for Tulip to execute authentication for connectors

    A Tulip inicia o processo de autenticação ao testar um Conector ou executar uma Função de Conector em um aplicativo.

    1. Redirecionar para o Servidor de Autorização:

    O aplicativo da Tulip redireciona o usuário para o Authorization Server (AS) juntamente com parâmetros específicos, incluindo response_type (definido como "code" para o Authorization Code Flow), client_id (atribuído na UI do conector), redirect_uri (predefinido pela Tulip), scope e audience (definidos na UI) e state (uma string aleatória para proteger contra ataques de Cross-Site Request Forgery).

    Exemplo: GET /authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=SCOPE&audience=AUDIENCE&state=STATE

    2. O usuário concede o consentimento:

    O servidor de autorização autentica o usuário e apresenta a ele uma tela de consentimento. O usuário pode analisar as permissões solicitadas e decidir se concede ou nega acesso ao aplicativo de terceiros.

    Observação: Na configuração de um conector give, o controle "Skip user consent prompt" permite controlar o atributo prompt na solicitação de autorização. Com esse controle desativado, será usado o valor consentimento; quando ativado, será usado o login.

    Se forem necessários valores adicionais do atributo prompt, entre em contato com support@tulip.co e habilitaremos outras opções para essa propriedade.
    :::

    3. Código de autorização:

    Se o usuário conceder consentimento, o Authorization Server gera um código de autorização e redireciona o usuário de volta para a Tulip junto com o código de autorização. O parâmetro state também é incluído, permitindo que o cliente verifique a integridade da resposta. Esse parâmetro de estado deve corresponder ao parâmetro de estado passado na Etapa 1.

    Exemplo de redirecionamento para o URI de redirecionamento do cliente:

    REDIRECT_URI?code=AUTHORIZATION_CODE&state=STATE

    4. Solicitação de token:

    O cliente agora tem o código de autorização e o utiliza para fazer uma solicitação segura, de servidor para servidor, ao ponto de extremidade do token do servidor de autorização. O cliente inclui o grant_type (definido como "authorization_code"), client_id, client_secret (um segredo conhecido apenas pelo cliente e pelo servidor de autorização), redirect_uri e o código de autorização.

    Exemplo de solicitação de token:

    grant\_type=authorization\_code&code=AUTHORIZATION\_CODE&redirect\_uri=REDIRECT\_URI&client\_id=CLIENT\_ID&client\_secret=CLIENT\_SECRET```
    
    
    ### 5. Resposta do token de acesso:
    
    
    Se o código de autorização for válido, o servidor de autorização responderá com um token de acesso e, opcionalmente, um token de atualização. O token de acesso é usado pelo cliente para se autenticar ao fazer solicitações à API protegida em nome do usuário.
    
    
    Exemplo de resposta de token:
    
    
    `{ "access_token": "ACCESS_TOKEN", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "REFRESH_TOKEN", "scope": "SCOPE"}`
    
    
    :::(Warning) (Services Not Using `expires_in`)
    
    :::
    
    
    ### 6. Acesso ao servidor de recursos:
    
    
    A Tulip agora pode usar o token de acesso obtido para fazer solicitações autorizadas ao Resource Server (API) em nome do usuário. O token de acesso geralmente é incluído no cabeçalho Authorization (Autorização) da solicitação HTTP.
    
    
    Exemplo de solicitação de API`:GET /api/resourceAuthorization: Portador ACCESS_TOKEN`
    
    
    ## Gerenciando a expiração do token com tokens de atualização
    
    
    Os servidores de autorização normalmente definem datas de expiração para os tokens para regular o acesso, com janelas de expiração variáveis, dependendo do sistema com interface. No entanto, os tokens de curta duração representam um desafio, pois a autenticação constante do usuário interrompe a experiência do usuário nos aplicativos Tulip.
    
    
    Para resolver esse problema, o OAuth oferece suporte a tokens de atualização. Embora opcionais, eles são altamente recomendados, pois simplificam a experiência do usuário, permitindo que a Tulip atualize os tokens sem problemas, sem a necessidade de intervenção manual dos operadores.
    
    
    ### Como a Tulip gerencia a atualização de tokens
    
    
    Quando a Tulip detecta que um token de acesso expirou, ela tenta automaticamente usar o token de atualização associado para obter um novo token. O objetivo principal é minimizar a reautenticação do usuário. As etapas a seguir descrevem a lógica executada pela Tulip:
    
    
    ![Token Refresh Flow](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/image%28399%29.png)
    
    
    1. **Detecção de expiração:**
    2. A Tulip identifica um token expirado com base em seu atributo `expires_in` recebido na [etapa 5](/r230/docs/oauth20-configuration-and-technical-details#5-access-token-response) do fluxo de autenticação.
    
    
    :::(Warning) (Services Not Using `expires_in`)
    
    :::
    
    
    1. **Tentativa de fluxo de token:**
    2. A Tulip inicia o fluxo de token usando o tipo de concessão `refresh_token`, substituindo o tipo de concessão usado no fluxo de autenticação inicial.
    3. **Validação do token:**
    4. Se um novo token for obtido, a Tulip o armazena e executa a função de conector solicitada pelo usuário.
    
    
    	* Se for bem-sucedido, os dados serão fornecidos ao tempo de execução do aplicativo Tulip.
    	* Se o novo token falhar com um erro OAuth, a Tulip tenta novamente o processo até 5 vezes, voltando à etapa 1 a cada vez.
    	* Se o novo token falhar com qualquer outro erro, um erro será exibido no tempo de execução do player.
    5. **Tratamento da ausência de token:**
    6. Se um novo token não for fornecido, o Tulip solicita que o usuário no player se submeta à autenticação, iniciando todo o processo de autenticação.
    7. Após a conclusão, a função do conector é executada e os dados são retornados.
    
    
    Ao implementar tokens de atualização, a Tulip garante uma experiência de usuário mais tranquila, gerenciando de forma inteligente a expiração e a renovação do token, minimizando as interrupções no fluxo de trabalho.
    
    
    ## Leitura adicional
    
    
    * [Introdução aos Hosts de Conectores da Tulip](/r230/docs/introduction-to-tulip-connector-hosts-1)
    * [Snapshotting do conector](/r230/docs/connector-snapshotting)
    * [Explicação sobre o OAuth2.0](/r230/docs/oauth20-explained)
    Post

    Este artigo foi útil?