Appendix B. Platform-Specific Implementation Details (Appendice B. Dettagli di implementazione specifici della piattaforma)
Questo documento definisce principalmente le migliori pratiche in modo generico, facendo riferimento a tecniche comunemente disponibili in una varietà di ambienti. Questa sezione non normativa documenta i dettagli di implementazione della migliore pratica per vari sistemi operativi.
I dettagli di implementazione qui riportati sono considerati accurati al momento della pubblicazione ma probabilmente cambieranno nel tempo. Si spera che tale cambiamento non invalidi i principi generici nel resto del documento e che tali principi dovrebbero avere la precedenza in caso di conflitto.
B.1. iOS Implementation Details (Dettagli di implementazione iOS)
Le app possono avviare una richiesta di autorizzazione nel browser, senza che l'utente lasci l'app, tramite la classe "SFSafariViewController" o il suo successore "SFAuthenticationSession", che implementano il pattern della scheda del browser integrata nell'app. Safari può essere utilizzato per gestire le richieste su versioni precedenti di iOS senza funzionalità di scheda del browser integrata nell'app.
Per ricevere la risposta di autorizzazione, sia i reindirizzamenti con schema URI per uso privato (chiamati "schema URL personalizzato") sia gli URI con schema "https" rivendicati (noti come "Universal Links") sono scelte valide. Le app possono rivendicare schemi URI per uso privato con la chiave "CFBundleURLTypes" nel file della lista di proprietà dell'applicazione, "Info.plist", e gli URI con schema "https" utilizzando la funzionalità Universal Links con un file di entitlement nell'app e un file di associazione ospitato sul dominio.
Gli URI con schema "https" rivendicati sono la scelta di reindirizzamento preferita su iOS 9 e superiori grazie alla prova di proprietà fornita dal sistema operativo.
Un esempio open-source completo è incluso nella libreria AppAuth for iOS and macOS [AppAuth.iOSmacOS].
B.2. Android Implementation Details (Dettagli di implementazione Android)
Le app possono avviare una richiesta di autorizzazione nel browser, senza che l'utente lasci l'app, tramite la funzionalità Android Custom Tab, che implementa il pattern della scheda del browser integrata nell'app. Il browser predefinito dell'utente può essere utilizzato per gestire le richieste quando nessun browser supporta le Custom Tab.
I fornitori di browser Android dovrebbero supportare il protocollo Custom Tab (fornendo un'implementazione della classe "CustomTabsService"), per fornire l'ottimizzazione dell'esperienza utente della scheda del browser integrata nell'app ai loro utenti. Chrome è uno di questi browser che implementa le Custom Tab.
Per ricevere la risposta di autorizzazione, gli schemi URI per uso privato sono ampiamente supportati tramite gli Android Implicit Intent. Gli URI di reindirizzamento con schema "https" rivendicati tramite Android App Links sono disponibili su Android 6.0 e superiori. Entrambi i tipi di URI di reindirizzamento sono registrati nel manifest dell'applicazione.
Un esempio open-source completo è incluso nella libreria AppAuth for Android [AppAuth.Android].
B.3. Windows Implementation Details (Dettagli di implementazione Windows)
Sia le app tradizionali che quelle Universal Windows Platform (UWP) possono eseguire richieste di autorizzazione nel browser dell'utente. Le app tradizionali utilizzano tipicamente un reindirizzamento di loopback per ricevere la risposta di autorizzazione, e l'ascolto sull'interfaccia di loopback è consentito dalle regole del firewall predefinite. Durante la creazione del socket di rete di loopback, le app dovrebbero (SHOULD) impostare l'opzione socket "SO_EXCLUSIVEADDRUSE" per impedire ad altre app di collegarsi allo stesso socket.
Le app UWP possono utilizzare reindirizzamenti con schema URI per uso privato per ricevere la risposta di autorizzazione dal browser, che porterà l'app in primo piano. Conosciuto sulla piattaforma come "URI Activation", lo schema URI è limitato a 39 caratteri di lunghezza e può includere il carattere ".", rendendo possibili schemi brevi basati su nomi di dominio inversi (come richiesto nella Sezione 7.1).
Le app UWP possono in alternativa utilizzare l'API Web Authentication Broker in modalità Single Sign-on (SSO), che è un user-agent esterno progettato per i flussi di autorizzazione. I cookie sono condivisi tra le invocazioni del broker ma non con il browser preferito dell'utente, il che significa che l'utente dovrà accedere nuovamente, anche se ha una sessione attiva nel proprio browser; ma la sessione creata nel broker sarà disponibile per le app successive che utilizzano il broker. Le personalizzazioni che l'utente ha apportato al proprio browser, come la configurazione di un gestore di password, potrebbero non essere disponibili nel broker. Per qualificarsi come user-agent esterno, il broker deve (MUST) essere utilizzato in modalità SSO.
Per utilizzare il Web Authentication Broker in modalità SSO, l'URI di reindirizzamento deve essere nella forma msapp://{appSID} dove "{appSID}" è l'identificatore di sicurezza (SID) dell'app, che può essere trovato nelle informazioni di registrazione dell'app o chiamando il metodo "GetCurrentApplicationCallbackUri". Mentre Windows applica l'autorità URI su tali reindirizzamenti, garantendo che solo l'app con il SID corrispondente possa ricevere la risposta su Windows, lo schema URI potrebbe essere rivendicato da app su altre piattaforme senza la stessa autorità presente; pertanto, questo tipo di reindirizzamento dovrebbe essere trattato in modo simile ai reindirizzamenti con schema URI per uso privato ai fini della sicurezza.
Un esempio open-source che dimostra questi pattern è disponibile [SamplesForWindows].
B.4. macOS Implementation Details (Dettagli di implementazione macOS)
Le app possono avviare una richiesta di autorizzazione nel browser predefinito dell'utente utilizzando le API della piattaforma per aprire gli URI nel browser.
Per ricevere la risposta di autorizzazione, gli schemi URI per uso privato sono una buona scelta di URI di reindirizzamento su macOS, poiché l'utente viene riportato direttamente all'app da cui ha avviato la richiesta. Questi sono registrati nella lista di proprietà delle informazioni del bundle dell'applicazione utilizzando la chiave "CFBundleURLSchemes". I reindirizzamenti IP di loopback sono un'altra opzione valida, e l'ascolto sull'interfaccia di loopback è consentito dalle regole del firewall predefinite.
Un esempio open-source completo è incluso nella libreria AppAuth for iOS and macOS [AppAuth.iOSmacOS].
B.5. Linux Implementation Details (Dettagli di implementazione Linux)
L'apertura della richiesta di autorizzazione nel browser predefinito dell'utente richiede un comando specifico della distribuzione: "xdg-open" è uno di questi strumenti.
Il reindirizzamento di loopback è la scelta di reindirizzamento raccomandata per le app desktop su Linux per ricevere la risposta di autorizzazione. Le app non dovrebbero (SHOULD NOT) impostare le opzioni socket "SO_REUSEPORT" o "SO_REUSEADDR" al fine di impedire ad altre app di collegarsi allo stesso socket.