Configurazione e dettagli tecnici di OAuth2.0

In questo articolo ci addentreremo nei dettagli tecnici di come Tulip implementa OAuth per l'autenticazione dei connettori. OAuth è potente, ma comporta una certa complessità. Questa guida intende rispondere a tutte le domande tecniche su ciò che Tulip supporta e su come è integrato.

Nota: Il flusso delle credenziali del client differisce in parte dal flusso del codice di autorizzazione. I passaggi 1 e 2 non sono rilevanti per il flusso delle credenziali del cliente.

Flusso del codice di autorizzazione Tulip

:::(Warning) (Servizi On-Prem) Gli endpoint Authorize e Token devono essere accessibili al cloud affinché Tulip esegua l'autenticazione per i connettori :::

Tulip avvia il processo di autenticazione quando testa un connettore o esegue una funzione connettore all'interno di un'applicazione.

1. Reindirizzamento al server di autorizzazione:

L'applicazione Tulip reindirizza l'utente all'Authorization Server (AS) con parametri specifici, tra cui response_type (impostato su "code" per Authorization Code Flow), client_id (assegnato nell'interfaccia utente del connettore), redirect_uri (predefinito da Tulip), scope e audience (impostati nell'interfaccia utente) e state (una stringa casuale per proteggersi da attacchi Cross-Site Request Forgery).

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

2. L'utente concede il consenso:

Il server di autorizzazione autentica l'utente e gli presenta una schermata di consenso. L'utente può esaminare le autorizzazioni richieste e decidere se concedere o negare l'accesso all'applicazione di terze parti.

:::(Warning) (Nota) Nella configurazione di un connettore give, il controllo "Salta la richiesta di consenso dell'utente" consente di controllare l'attributo prompt sulla richiesta di autorizzazione. Se questo controllo è disabilitato, verrà utilizzato il valore consenso, mentre se è abilitato verrà utilizzato il valore login.

Se sono necessari altri valori dell'attributo prompt, contattate support@tulip.co e abiliteremo altre opzioni per questa proprietà:

3. Codice di autorizzazione:

Se l'utente concede il consenso, il server di autorizzazione genera un codice di autorizzazione e reindirizza l'utente a Tulip insieme al codice di autorizzazione. Viene incluso anche il parametro state, che consente al client di verificare l'integrità della risposta. Questo parametro di stato deve corrispondere al parametro di stato passato al passo 1.

Esempio di reindirizzamento all'URI di reindirizzamento del cliente:

REDIRECT_URI?code=AUTHORIZATION_CODE&state=STATE

4. Richiesta del token:

Il client ha ora il codice di autorizzazione e lo usa per fare una richiesta sicura, da server a server, all'endpoint del token dell'Authorization Server. Il client include il grant_type (impostato su "authorization_code"), il client_id, il client_secret (un segreto noto solo al client e al server di autorizzazione), il redirect_uri e il codice di autorizzazione.

Esempio di richiesta di token:

grant\_type=authorization\_code&code=AUTHORIZATION\_CODE&redirect\_uri=REDIRECT\_URI&client\_id=CLIENT\_ID&client\_secret=CLIENT\_SECRET ```


### 5. Risposta del token di accesso:


Se il codice di autorizzazione è valido, il server di autorizzazione risponde con un token di accesso e, facoltativamente, un token di aggiornamento. Il token di accesso viene utilizzato dal client per autenticarsi quando effettua richieste all'API protetta per conto dell'utente.


Esempio di risposta al token:


`{"access_token": "ACCESS_TOKEN", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "REFRESH_TOKEN", "scope": "SCOPE" }`


### 6. Accesso al server delle risorse:


Tulip può ora utilizzare il token di accesso ottenuto per effettuare richieste autorizzate al Resource Server (API) per conto dell'utente. Il token di accesso è solitamente incluso nell'intestazione Authorization della richiesta HTTP.


Esempio di richiesta API:`GET /api/resource Autorizzazione: Portatore ACCESS_TOKEN`


## Gestione della scadenza dei token con i token di aggiornamento


I server di autorizzazione di solito impostano date di scadenza per i token per regolare l'accesso, con finestre di scadenza variabili a seconda del sistema interfacciato. Tuttavia, i token di breve durata rappresentano una sfida, poiché l'autenticazione costante dell'utente disturba l'esperienza dell'utente nelle applicazioni Tulip.


Per risolvere questo problema, OAuth supporta i token di aggiornamento. Pur essendo facoltativi, sono altamente raccomandati in quanto semplificano l'esperienza dell'utente consentendo a Tulip di aggiornare i token senza problemi, senza richiedere l'intervento manuale degli operatori.


### Come Tulip gestisce l'aggiornamento dei token


Quando Tulip rileva che un token di accesso è scaduto, tenta automaticamente di utilizzare il token di aggiornamento associato per ottenere un nuovo token. L'obiettivo primario è ridurre al minimo la riautenticazione degli utenti. Le fasi seguenti illustrano la logica eseguita da Tulip:


![Token Refresh Flow](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/image%28399%29.png)


1. **Rilevamento della scadenza:**
2. Tulip identifica un token scaduto in base all'attributo `expires_in` ricevuto nel [passaggio 5](/r230/docs/oauth20-configuration-and-technical-details#5-access-token-response) del flusso di autenticazione.
3. **Tentativo di flusso di token:**
4. Tulip avvia il flusso di token utilizzando il tipo di sovvenzione `refresh_token`, che sostituisce il tipo di sovvenzione `authorization_code` utilizzato nel flusso di autenticazione iniziale.
5. **Convalida del token:**
6. Se si ottiene un nuovo token, Tulip lo memorizza e procede all'esecuzione della funzione connettore richiesta dall'utente.


	* In caso di successo, i dati vengono forniti al runtime dell'applicazione Tulip.
	* Se il nuovo token fallisce con un errore OAuth, Tulip ritenta il processo fino a 5 volte, tornando ogni volta al punto 1.
	* Se il nuovo token fallisce con qualsiasi altro errore, viene visualizzato un errore nel runtime del lettore.
7. **Gestione dell'assenza di token:**
8. Se non viene fornito un nuovo token, Tulip chiede all'utente del lettore di sottoporsi all'autenticazione, avviando l'intero processo di autenticazione.
9. Al termine, viene eseguita la funzione connettore e vengono restituiti i dati.


Implementando i token di aggiornamento, Tulip garantisce un'esperienza utente più fluida gestendo in modo intelligente la scadenza e il rinnovo dei token, riducendo al minimo le interruzioni del flusso di lavoro.


## Ulteriori letture


* [Introduzione agli host del connettore Tulip](/r230/docs/introduction-to-tulip-connector-hosts-1)
* [Snapshotting del connettore](/r230/docs/connector-snapshotting)
* [OAuth2.0 spiegato](/r230/docs/oauth20-explained)