Flussi di autorizzazione OAuth

Ad esempio, quando si apre l'app mobile Salesforce per accedere ai dati Salesforce, si avvia un flusso di autorizzazione OAuth 2.0. In questo flusso, l'organizzazione Salesforce è il server di risorse che ospita la risorsa protetta. L'app mobile Salesforce è il client che richiede l'accesso. L'utente è il titolare della risorsa che consente all'app mobile Salesforce di accedere e gestire i dati Salesforce sul Web in qualsiasi momento. L'organizzazione Salesforce, che funziona da server di autorizzazione, concede l'accesso all'app mobile Salesforce generando un token di accesso. Di seguito viene descritto il flusso nel dettaglio.

1. Si apre l'app mobile Salesforce.
2. Viene visualizzata una richiesta di autenticazione in cui devono essere inseriti il nome utente e la password.
3. L'app mobile Salesforce invia le credenziali dell'utente a Salesforce e avvia il flusso di autorizzazione OAuth.
4. Salesforce invia i token di accesso e aggiornamento dell'app mobile come conferma dell'avvenuta convalida dell'utente e dell'app mobile.
5. L'utente approva la richiesta per concedere l'accesso all'app mobile Salesforce.
6. L'app mobile Salesforce viene avviata.

Dopo questo flusso iniziale, l'app mobile Salesforce viene avviata immediatamente quando è attiva la sessione. Se la sessione non è aggiornata, l'app mobile Salesforce utilizza il token di aggiornamento dell'autorizzazione iniziale per ottenere una sessione aggiornata.

Si confronti questo approccio con quello che prevede di fornire nome utente e password a un'applicazione client perché possa accedere per nostro conto a un server di risorse. L'app client assume effettivamente l'identità dell'utente, con lo stesso accesso ai dati. Se l'app client non è più considerata affidabile, è necessario cambiare la password sul server delle risorse, sebbene questa operazione rappresenti un contrattempo e un rischio per la sicurezza. Per questo motivo, l'autorizzazione OAuth è la soluzione migliore.

Flussi di autorizzazione OAuth e app client esterne

Tutti i flussi di autorizzazione OAuth, ad eccezione del flusso Asserzione SAML, richiedono la definizione di un'app client esterna. Il framework dell'app client esterna consente a un'applicazione di terze parti di integrarsi con Salesforce utilizzando API e protocolli standard come SAML, OAuth e OpenID Connect. Le app client esterne utilizzano questi protocolli per autenticare, autorizzare e integrare applicazioni e fornitori di servizi esterni. Le applicazioni esterne integrate con Salesforce possono essere eseguite sulla piattaforma Customer Success, sui dispositivi, sugli abbonamenti SaaS o su altre piattaforme. Nell'esempio precedente, l'app mobile Salesforce si integra con l'organizzazione utilizzando un'app client esterna.

Nota Gli utenti possono autorizzare un'app client esterna ad accedere ai dati protetti più di una volta, ad esempio un computer portatile, un computer desktop e un dispositivo mobile. L'impostazione predefinita è cinque autorizzazioni per app client esterna per utente. Se un utente tenta di concedere l'accesso a un'app client esterna dopo aver raggiunto il limite dell'organizzazione, il token di accesso inutilizzato per il periodo di tempo più lungo viene revocato. Le nuove app client esterne OAuth 2.0 che utilizzano il flusso server Web vengono approvate per più dispositivi dopo che l'utente ha concesso l'accesso. Il flusso utente-agente richiede ogni volta l'approvazione dell'utente.

Casi d'uso dei flussi di autorizzazione OAuth

In qualità di sviluppatore Salesforce, l'utente può scegliere tra diversi flussi di autorizzazione OAuth. Nello scegliere il flusso più adeguato per la propria applicazione, tenere presenti i seguenti casi d'uso.

Importante Per alcuni flussi valgono delle importanti considerazioni sulla sicurezza. Ad esempio, quando si usa il flusso server Web è necessario archiviare il segreto client in modo protetto. Si consiglia di evitare i flussi utente-agente e nome utente-password, perché trasmettono le credenziali. Scegliere invece un flusso che evita che l'applicazione debba gestire, memorizzare e proteggere le credenziali.

• Flussi Headless Identity
  È possibile utilizzare le API Headless Identity per configurare l'accesso, la registrazione, l'accesso senza password e altro ancora per un'app esterna alla piattaforma. I flussi Headless Identity sono disponibili solo per gli utenti esterni, noti anche come clienti e partner.
• Creazione di un'esperienza Single Sign-On nativa nell'app
  Con un parametro facoltativo nel flusso server Web OAuth 2.0 e nel flusso utente-agente è possibile creare un'esperienza Single Sign-On (SSO) che faccia risultare l'app di terze parti integrata con un provider di identità esterno. Con questo processo, è possibile collegare un flusso OAuth a un flusso SSO mantenendo il controllo dell'esperienza all'interno dell'app. Questo parametro è supportato per i siti Experience Cloud, quindi è possibile utilizzare questa funzionalità per aggiungere SSO a un'implementazione di Identità headless. Questo parametro è supportato anche per Dominio personale.
• Flusso server Web OAuth 2.0 per l'integrazione delle app Web
  Per integrare un'app Web esterna con l'API Salesforce, utilizzare il flusso server Web OAuth 2.0, che implementa il tipo di grant codice di autorizzazione OAuth 2.0. Con questo flusso, il server che ospita l'app Web deve essere in grado di proteggere l'identità dell'app client esterna, definita dall'ID client e dal segreto client.
• Flusso utente-agente OAuth 2.0 per l'integrazione di applicazioni desktop o mobili
  Con il flusso utente-agente OAuth 2.0, gli utenti autorizzano un'applicazione desktop o mobile ad accedere ai dati utilizzando un browser esterno o incorporato. Possono usare questo flusso anche le applicazioni client eseguite in un browser che utilizza un linguaggio di script, ad esempio JavaScript. Questo flusso utilizza il tipo di grant implicito OAuth 2.0.
• Flusso token di aggiornamento OAuth 2.0 per le sessioni rinnovate
  Il flusso token di aggiornamento OAuth 2.0 rinnova i token di accesso emessi dal flusso server Web OAuth 2.0 o dal flusso utente-agente OAuth 2.0.
• Flusso exchange token OAuth 2.0
  Quando Salesforce è solo uno dei componenti di un'architettura che include un provider di identità centrale con più app e micro servizi, utilizzare il flusso exchange token OAuth 2.0 per semplificare gli schemi di integrazione. Con questo flusso, scambiare i token dei provider di identità esterni con i token Salesforce e concedere l'accesso ai dati Salesforce.
• Autorizzazione OAuth 2.0 e gestione delle sessioni per le app ibride
  La gestione delle sessioni Web per le app ibride è complessa con un flusso utente-agente tipico o un flusso del token di aggiornamento. In questi flussi, un'app ibrida imposta i cookie di dominio necessari e collega un token di accesso in una sessione Web. Tuttavia, il token di accesso e la sessione Web non sono connessi in questi flussi. È necessario invece tenere traccia della scadenza dei token di accesso e di aggiornamento e della sessione Web e quindi ricollegare manualmente la sessione per evitare un'interruzione del servizio. Per evitare questo processo complesso, utilizzare i flussi dell'app ibrida OAuth 2.0. Questi flussi connettono i token di accesso e di aggiornamento alla sessione Web per fornire alle app ibride la gestione diretta delle sessioni Web.
• Flusso bearer JWT OAuth 2.0 per l'integrazione da server a server
  In alcuni casi, è preferibile autorizzare i server per accedere ai dati senza eseguire l'accesso in modo interattivo ogni volta che i server si scambiano informazioni. Per questi casi, è possibile utilizzare il flusso bearer token Web JSON OAuth 2.0 (JWT). Questo flusso utilizza un certificato per firmare la richiesta JWT e non richiede un'interazione esplicita dell'utente. Tuttavia, il flusso richiede la preventiva approvazione dell'applicazione client.
• Flusso credenziali client OAuth 2.0 per l'integrazione da server a server
  A volte può essere utile condividere direttamente le informazioni tra due applicazioni senza l'intervento di un utente. Per casi come questi è possibile utilizzare il flusso credenziali client OAuth 2.0. In questo flusso, l'applicazione client scambia le proprie credenziali client definite nell'applicazione client esterna (la chiave consumatore e il segreto consumatore) con un token di accesso. Questo flusso elimina la necessità di un'interazione utente esplicita, benché richieda di indicare un utente integrazione per eseguire l'integrazione. È possibile utilizzare questo flusso come alternativa più sicura al flusso password-nome utente OAuth 2.0.
• Registrazione client dinamica di OpenID Connect per i gateway API esterni
  Benché non sia un tipico flusso di autorizzazione, è possibile utilizzare la registrazione client dinamica di OpenID Connect per abilitare l'istanza di Salesforce come server di autorizzazione OAuth indipendente per proteggere le risorse ospitate in un gateway API esterno.
• Generazione di un token di accesso iniziale
  La registrazione client dinamica OpenID Connect consente ai client OAuth, tramite le applicazioni connesse, di registrare automaticamente le applicazioni connesse in Salesforce. Per autenticare le richieste di registrazione client, Salesforce richiede un token di accesso iniziale.
• Introspezione token OpenID Connect
  Come parte del processo di autorizzazione, l'introspezione dei token consente a tutte le applicazioni connesse OAuth di verificare lo stato attuale di un token di accesso o di aggiornamento OAuth 2.0. Il server di risorse o le applicazioni connesse inviano l'ID e il segreto client dell'applicazione client al server di autorizzazione, avviando un flusso di autorizzazione OAuth. Come parte di questo flusso, il server di autorizzazione convalida (o analizza) il token di accesso dell'applicazione client. Se il token di accesso è attuale e valido, viene concesso l'accesso all'applicazione client.
• Flusso di dispositivo OAuth 2.0 per l'integrazione IoT
  Per integrare le applicazioni eseguite su dispositivi con funzionalità limitate in termini di input o visualizzazione, ad esempio Smart TV, elettrodomestici e altri dispositivi IoT, utilizzare il flusso di dispositivo OAuth 2.0. Anche le applicazioni da riga di comando possono utilizzare questo flusso. Gli utenti possono collegare queste applicazioni a Salesforce accedendo a un browser su un dispositivo con funzioni di input più avanzate come un computer desktop o un dispositivo mobile.
• Flusso token asset OAuth 2.0 per la protezione dei dispositivi connessi
  Per integrare i dispositivi IoT con l'API Salesforce, utilizzare il flusso token asset OAuth 2.0. I token asset sono token di autenticazione JWT basati su standard aperti per la verifica e la protezione delle richieste da parte dei dispositivi connessi. I token asset identificano il dispositivo per un servizio di backend che elabora il flusso di dati e di eventi proveniente dal dispositivo. Consentono la registrazione dei dati del dispositivo sulla piattaforma Salesforce e il loro collegamento ai dati di Salesforce CRM relativi a cliente, account o referente.
• Demo del flusso token asset
  Per una breve demo sui token asset, è possibile utilizzare l'applicazione dimostrativa Asset Token Explorer, che semplifica l'acquisizione iniziale di un token di accesso e il suo scambio con il token asset.
• Flusso nome utente-password OAuth 2.0 per scenari speciali
  È possibile utilizzare il flusso nome utente-password per autorizzare un client, tramite un'applicazione connessa, che ha già le credenziali dell'utente. Tuttavia, si consiglia di evitare questo flusso perché trasmette le credenziali avanti e indietro. Utilizzarlo solo se il livello di fiducia tra il titolare della risorsa e il client è alto, il client è un'applicazione proprietaria, Salesforce ospita i dati e sono disponibili altri tipi di grant. In questi casi, impostare le autorizzazioni utente per limitare al massimo l'accesso e proteggere le credenziali memorizzate da eventuali accessi non autorizzati.
• Blocco dei flussi di autorizzazione per migliorare la sicurezza
  I flussi utente-agente e nome utente-password OAuth 2.0 sono considerati non sicuri e non sono consigliati. Per una maggiore sicurezza, si consiglia vivamente di bloccare questi flussi in Salesforce per impedire agli sviluppatori di utilizzarli per creare nuove integrazioni. Se l'organizzazione è stata creata nel rilascio Summer '23 o successivo, il flusso nome utente-password è bloccato per impostazione predefinita. Se necessario, è possibile abilitare il flusso nome utente-password. Se esistono integrazioni che utilizzano il flusso utente-agente o nome utente-password, aggiornarle a un flusso OAuth 2.0 più sicuro. È anche possibile bloccare il flusso Codice di autorizzazione e credenziali, utilizzato per configurare in modo sicuro un processo di accesso headless. È possibile bloccare alcuni flussi che non utilizzano l'estensione PKCE.
• Flusso di asserzioni bearer SAML OAuth 2.0 per le applicazioni già autorizzate
  Con il flusso di asserzioni bearer SAML OAuth 2.0, un client, tramite un'applicazione connessa, può utilizzare un'autorizzazione precedente specificando un'asserzione SAML 2.0 firmata per richiedere un token di accesso OAuth. La firma digitale applicata all'asserzione SAML autentica l'applicazione autorizzata. Un'asserzione SAML è un token di protezione XML emesso da un provider di identità e utilizzato da un fornitore di servizi. Questi fa affidamento sul suo contenuto per identificare il soggetto dell'asserzione a fini di protezione.
• Flusso asserzioni SAML per l'accesso all'API
  Il flusso asserzioni SAML è una soluzione alternativa per le organizzazioni che utilizzano SAML per accedere a Salesforce e desiderano accedere all'API allo stesso modo. I client possono effettuare la federazione con l'API mediante un'asserzione SAML analogamente alla federazione con Salesforce per il Single Sign-On sul Web (Web SSO). È possibile utilizzare questo flusso di asserzioni senza un'applicazione connessa.
• Errori di autorizzazione OAuth 2.0
  Durante l'autorizzazione OAuth si possono verificare errori. Ad esempio, un utente nega l'accesso all'applicazione connessa o i parametri di richiesta non sono corretti. Quando si verificano errori, il server di autorizzazione invia un errore all'URL di richiamata con un codice di errore.
• Flusso OAuth 1.0
  Se l'organizzazione utilizza il protocollo OAuth 1.0, usare questo flusso di autorizzazione per integrare un client, tramite un'applicazione connessa, con l'API Salesforce.
• Codici di errore di autorizzazione OAuth 1.0.A
  Durante l'autorizzazione si possono verificare errori. Ad esempio, l'URL di richiamata non è valido. Quando si verificano degli errori durante il flusso OAuth 1.0, Salesforce restituisce un codice di errore.