Opzioni di autenticazione
Prima di usare qualsiasi connettore in App per la logica di Azure, Power Automate o Power Apps, l'utente deve creare una connessione autenticandosi al servizio di rete. Quando si crea un connettore personalizzato, è possibile definire la modalità di autenticazione della persona che userà il connettore. Il tipo di autenticazione può essere selezionato nella scheda Sicurezza della procedura guidata per i connettori online. Le informazioni aggiuntive richieste dipendono dallo schema di autenticazione selezionato.
Nessuna autenticazione
Se è selezionata l'opzione Nessuna autenticazione, non sono necessarie ulteriori informazioni. L'utente non deve autenticarsi per creare una connessione al connettore personalizzato e qualsiasi utente anonimo può usare il connettore. Questa opzione viene usata solo quando l'API consente l'uso anonimo.
Autenticazione di base
Il tipo di autenticazione più semplice è Autenticazione di base, che richiede all'utente di fornire nome utente e password per creare la connessione.
I valori inseriti sotto la colonna Etichetta parametro non corrispondono al nome utente o alla password effettivi, ma sono le etichette di questi campi visualizzate dall'utente durante la creazione della connessione.
Nell'esempio precedente, all'utente viene chiesto di inserire Utente e Password per creare una connessione. È necessario associare le etichette ai nomi usati dall'API per chiarire a chi crea una connessione quali valori usare.
Tutte le connessioni del servizio che usano Autenticazione di base devono applicare il protocollo HTTPS sicuro per evitare di inviare credenziali non crittografate in rete.
Autenticazione della chiave API
La chiave API è uno schema di autenticazione molto diffuso usato dai servizi Web. Ad esempio, Funzioni di Microsoft Azure include parametri di codice nel modello predefinito.
Verificare che i seguenti valori siano definiti:
Etichetta parametro: l'etichetta per la richiesta all'utente quando viene creata una nuova connessione.
Nome parametro: il nome del parametro che contiene il valore della chiave durante ogni richiesta di servizio.
Posizione parametro: consente ai creatori di inviare la chiave API nell'intestazione della richiesta o nella stringa di query quando chiamano il servizio sottostante.
Nell'esempio precedente, l'utente che sta creando una nuova connessione vedrà il seguente messaggio.
Il valore fornito verrà inviato al servizio sottostante come un'intestazione della richiesta X-API-Key personalizzata.
Il modello di Funzioni di Azure predefinito può usare il codice come nome del parametro e quindi inviarlo nell'ambito della query impostando il percorso del parametro su Query in modo che l'URL del servizio sia simile a:
https://functionurl.azurewebsites.net?code=user-supplied-code/
Come per Autenticazione di base, consigliamo di usare lo schema di autenticazione Chiave API solo con un protocollo HTTPS per evitare di inviare le chiavi non crittografate.
Autenticazione OAuth 2.0
Lo schema di autenticazione OAuth 2.0 è disponibile solo per i connettori online. Oltre a fornire supporto per l'autenticazione generica OAuth 2.0, la piattaforma fornisce implementazioni per servizi specifici, tra cui Microsoft Entra ID, GitHub, l'account Microsoft e altro ancora. I modelli dei provider di identità predefiniti, se selezionati, compilano molti dei campi richiesti da OAuth 2.0 con valori specifici del provider, velocizzando l'immissione dei dati.
Le informazioni aggiuntive raccolte dipendono dal provider di identità. Il provider OAuth 2.0 generica richiede i seguenti parametri.
Parametro | Descrizione |
---|---|
ID client | Identificatore dell'app OAuth nel sistema di destinazione, immesso manualmente o generato dal provider al momento della registrazione dell'app. |
Segreto client | Segreto associato all'app OAuth, generato dal provider. La maggior parte dei provider può anche revocare i segreti esistenti e rilasciarne di nuovi. |
URL autorizzazione | URL usato per l'accesso dell'utente e l'autorizzazione dell'applicazione, ad esempio https://www.facebook.com/v9.0/dialog/oauth o https://login.salesforce.com/services/oauth2/authorize . |
URL token | URL usato per recuperare un token dopo che l'app è stata autorizzata dall'utente, ad esempio https://graph.facebook.com/v9.0/oauth/access_token o https://mycompany.salesforce.com/mycompany.salesforce.com . |
URL di aggiornamento | URL usato per recuperare un nuovo token con un token di aggiornamento dopo che quello originale è scaduto. Questo URL di solito è uguale a quello del token per la maggior parte dei servizi. |
Ambito | Stringa che rappresenta le autorizzazioni richieste all'utente. Lasciare vuoto questo parametro o fare riferimento alla documentazione del provider per specificare l'ambito di autorizzazione richiesto dall'app. |
Assicurarsi di registrare il connettore con il provider di identità come applicazione client. I dettagli di registrazione specifici dipendono dal provider e sono documentati dal provider di identità. Ad esempio, per l'autenticazione con Facebook, un creatore deve creare un'app Facebook con i relativi strumenti di sviluppo. Poiché i parametri ID client e Segreto client fanno parte delle specifiche di OAuth 2.0, vengono forniti da tutti i provider di identità OAuth 2.0 nell'ambito della registrazione dell'app. Un valore che deve essere incluso nella registrazione dell'app è URL di reindirizzamento. Questo valore è inizialmente vuoto, ma diventa disponibile quando la configurazione del connettore viene salvata. Può quindi essere copiato e salvato nella registrazione del connettore con il provider di identità.
La maggior parte dei provider specifici richiede solo l'ID client, il segreto client e l'ambito facoltativo perché tutti gli URL sono predefiniti per un servizio specifico.
Una volta pubblicato e reso disponibile il connettore, agli utenti verrà chiesto di inserire le proprie credenziali per accedere al servizio durante il processo di creazione della connessione. Queste credenziali verranno usate dall'applicazione per ottenere un token di autorizzazione. Per ogni richiesta, il token di autorizzazione verrà inviato al servizio tramite l'intestazione di autorizzazione standard.
Il token di autorizzazione ha una durata breve e il runtime del connettore userà il processo di aggiornamento per il rinnovo in modo che gli utenti del connettore non siano coinvolti nel processo di aggiornamento.
Autenticazione di Windows
L'opzione di autenticazione di Windows è disponibile solo per le connessioni che usano il gateway dati locale, quando la casella di controllo Connetti tramite gateway dati locale è impostata sulla scheda Generale. Non sono necessarie informazioni aggiuntive per lo schema di autenticazione di Windows.
Quando viene creata una nuova connessione, l'utente dovrà fornire le credenziali di Windows per il servizio e quindi selezionare uno dei gateway locali installati.
La specifica OpenAPI usata dalla piattaforma include sia la definizione di Chiave API che di Autenticazione di base. È anche possibile modificarle direttamente online con l'editor Swagger. Altri schemi di autenticazione archiviano le informazioni di autenticazione separatamente come proprietà estese del connettore. Sebbene queste informazioni non siano disponibili per la modifica diretta dell'origine online, è possibile modificarle con lo strumento paconn. L'interfaccia della riga di comando consente lo scripting del processo di distribuzione del connettore in cui è richiesta la distribuzione automatica.
I connettori personalizzati supportano diversi schemi di autenticazione per soddisfare i requisiti di accesso ai servizi API REST protetti. Quando i servizi API vengono distribuiti e protetti all'interno di un ambiente Azure AD, l'infrastruttura del connettore offre altri vantaggi. La prossima unità offre altre informazioni sulle specifiche di Azure AD.