Che cos'è OAuth2.0?

Esplorazione di OAuth2.0

Benvenuti all'esplorazione di OAuth2.0, un protocollo di autenticazione potente ma spesso incompreso all'interno dell'universo Tulip. In questo articolo sveleremo i fondamenti, vi guideremo attraverso i flussi di autenticazione supportati da Tulip, demistificheremo la configurazione del vostro connettore iniziale e condivideremo consigli rapidi per un inizio senza intoppi.

OAuth2.0 può essere complicato e, per mantenere le cose concise, abbiamo omesso alcuni aspetti tecnici dettagliati da questo articolo. Se desiderate un'immersione più approfondita nella gestione di Tulip dei token di aggiornamento, nella gestione dell'ambito e del pubblico e nelle configurazioni personalizzate dei connettori, vi consigliamo di consultare la guida tecnica OAuth2.0.

Tipi di autenticazione

Tulip supporta tre tipi di autenticazione OAuth2.0: OAuth2.0 (Account di servizio), OAuth2.0 (Credenziali utente) e OAuth2.0 (Credenziali client). La differenza fondamentale sta nel modo in cui le credenziali vengono condivise tra gli utenti e nel flusso che viene eseguito rispetto alla specifica OAuth. Un elenco completo e una descrizione dei flussi OAuth unici sono disponibili qui: https://frontegg.com/blog/oauth-flows.

:::(Info) (Nota) Nelle versioni precedenti di Tulip, OAuth2.0 (Account di servizio) era chiamato OAuth2 (Admin) e OAuth2.0 (Credenziali utente) era chiamato OAuth2 (Operatore):

Flusso del codice di autorizzazione:

• OAuth2.0 (Account di servizio): Utilizza le credenziali fornite durante il test del connettore per tutti gli utenti del Tulip Player. Ideale per le credenziali condivise nell'organizzazione. Se le credenziali scadono, è necessaria una nuova autenticazione da parte dell'amministratore.
• OAuth2.0 (credenziali utente): Segmenta l'autenticazione in base all'utente connesso a Tulip Player. Se un utente non si è autenticato o l'autenticazione scade, l'utente subisce il flusso OAuth all'interno di Tulip Player.

Flusso delle credenziali del cliente:

• OAuth2.0 (credenziali del cliente): Questo tipo di concessione è utilizzato da Tulip per ottenere un token di accesso autenticandosi con il server di autorizzazione utilizzando le credenziali del cliente (ID cliente e segreto cliente), in genere per accedere alle risorse per conto proprio piuttosto che per conto di un utente.

Svelare le basi

Prima di addentrarci nei dettagli, suggeriamo di familiarizzare con gli ambienti e di ottenere una panoramica degli host del connettore e delle loro funzioni.

OAuth2.0 serve come meccanismo per Tulip (il client) per stabilire la propria identità con i sistemi aziendali.

Flusso del codice di autorizzazione

:::(Warning) (Attenzione) Per completare il processo di autenticazione dell'utente, il browser deve consentire i pop-up. Se il connettore è configurato con più ambienti, ogni ambiente aprirà una finestra pop-up separata durante l'autenticazione.

Come verificare se i pop-up sono abilitati in Chrome:

1. Aprire Chrome e fare clic sul menu a tre punti nell'angolo superiore destro della finestra.
2. Selezionare Impostazioni dal menu a discesa.
3. Scorrere verso il basso e fare clic su Privacy e sicurezza.
4. Nella sezione "Privacy e sicurezza", fare clic su Impostazioni del sito.
5. Scorrere verso il basso e fare clic su Pop-up e reindirizzamenti.
6. Assicurarsi che la levetta sia impostata su Consenti pop-up, oppure aggiungere manualmente il sito web all'elenco dei siti autorizzati a mostrare i pop-up.

Se i pop-up sono bloccati, Chrome visualizzerà una piccola icona nella barra degli indirizzi ogni volta che un pop-up viene bloccato. È possibile fare clic su questa icona per consentire rapidamente la visualizzazione dei pop-up da Tulip:

L'accesso viene concesso attraverso un handshake e Tulip supporta principalmente l'Authorization Code Flow, il flusso OAuth più comune. Ecco una breve panoramica di come si svolge questo flusso:

1. L'utente avvia il flusso facendo clic sul pulsante Test prima di salvare un connettore.
2. Tulip comunica con il server di autorizzazione del provider OAuth, condividendo parametri specifici come l'identità del cliente, gli ambiti (ciò a cui si sta tentando di accedere) e altri dettagli rilevanti.
3. Il server di autorizzazione chiede all'utente di concedere l'accesso, come illustrato di seguito:

1. Quando l'utente acconsente, il server di autorizzazione genera un codice di autorizzazione e conclude la finestra di autenticazione.
2. Armato di un codice di autorizzazione, Tulip richiede in modo sicuro un token raggiungendo l'endpoint del token, fornendo il codice di autorizzazione, l'ID del cliente, il segreto del cliente e altre proprietà.
3. Dopo aver convalidato il codice di autorizzazione, il server risponde con un token e, facoltativamente, con un token di aggiornamento. Questo token serve per le richieste autorizzate dall'utente.
4. Tulip può ora eseguire le richieste per conto degli utenti, con il token fornito per l'autorizzazione.

Vedere i diagrammi seguenti per capire il percorso di esecuzione:

Flusso delle credenziali del cliente

Il flusso delle credenziali client è usato principalmente per far interagire due sistemi aziendali. Questo flusso viene configurato una sola volta e poi condiviso da tutti gli utenti.

1. L'utente avvia il flusso facendo clic sul pulsante Prova prima di salvare un connettore.
2. Tulip comunica con il server di autorizzazione del provider OAuth, condividendo parametri specifici come l'identità del cliente, gli ambiti (ciò a cui si sta tentando di accedere) e altri dettagli rilevanti.
3. Il server di autorizzazione restituisce un token di accesso, supponendo che l'ID cliente e il Segreto cliente siano accurati. Opzionalmente, può essere restituito anche un token di aggiornamento. Questo token serve per le richieste autorizzate dall'utente.
4. Tulip può ora eseguire le richieste per conto degli utenti, con il token di autorizzazione fornito.

Configurazione di OAuth

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

URL del codice di autorizzazione

È l'URL che Tulip contatta nel passaggio 2 del flusso del codice di autenticazione. Si trova nella documentazione dell'API del provider OAuth, di solito termina con /auth o /authorize.

Nota: Questo campo non è presente per le credenziali del cliente.

URL del token di accesso

Dopo la risposta del server di autorizzazione, viene effettuata una richiesta all'URL del token di accesso per ottenere un token per l'autenticazione. Generalmente termina con /token.

Nota: Questo campo non è presente per le credenziali del client.

ID cliente e Segreto cliente

Generato dall'interfaccia utente del provider OAuth, l'ID cliente viene passato con la richiesta iniziale di un codice di autorizzazione. L'ID cliente e il Segreto cliente accompagnano tutte le richieste di token.

Pubblico e ambito

Audience specifica le risorse specifiche a cui l'utente vuole accedere, mentre Scope definisce le azioni desiderate su queste risorse. Entrambi sono trasmessi durante la richiesta di codice di autorizzazione al punto 2.

Opzioni aggiuntive

• Invia i dati della richiesta di token come JSON: cambia il tipo di codifica della richiesta inviata all'URL del token. Attivare se necessario per integrazioni specifiche.
• Invia intestazione di autenticazione per la richiesta di aggiornamento: Aggiunge un'intestazione supplementare alle richieste di aggiornamento, se abilitata.
• Salta il prompt del consenso dell'utente: Controlla l'attributo prompt della richiesta del codice di autenticazione. Disabilitato lo imposta su consenso, mentre abilitato lo imposta su login, lasciando che sia il provider OAuth a decidere quale schermata di login visualizzare.

:::(Warning) (Nota) Per alcune integrazioni, escludere o impostare l'attributo prompt su nessuno. Rivolgersi a support@tulip.co per ulteriori funzionalità:

Scavare più a fondo

Volete saperne di più? Esplorate questi articoli:

• Configurazione e dettagli tecnici di OAuth2.0
• Come eseguire una funzione connettore in più ambienti