Che cos'è OAuth2.0?
  • 28 Aug 2024
  • 4 Minuti da leggere
  • Contributori

Che cos'è OAuth2.0?


Sommario dell'articolo

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. La riautenticazione dell'amministratore è necessaria se le credenziali scadono.
  • 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

L'accesso viene concesso attraverso un handshake e Tulip supporta principalmente il flusso del codice di autorizzazione, 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:Token Request

OAuth2 Graphic

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.

Client Credentials Flow

Configurazione di OAuth

:::(Warning) (Servizi On-Prem) Gli endpoint Authorize e Token devono essere accessibili al cloud per consentire a Tulip di eseguire l'autenticazione dei connettori:

OAuth Configuration

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 vengono 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à:

Approfondimenti

Volete saperne di più? Esplorate questi articoli:


Questo articolo è stato utile?