7. Receiving the Authorization Response in a Native App (Ricezione della risposta di autorizzazione in un'applicazione nativa)
Esistono diverse opzioni di URI di reindirizzamento disponibili per le applicazioni native per ricevere la risposta di autorizzazione dal browser, la cui disponibilità ed esperienza utente varia a seconda della piattaforma.
Per supportare completamente questa migliore pratica, i server di autorizzazione devono (MUST) offrire almeno le tre opzioni di URI di reindirizzamento descritte nelle seguenti sottosezioni alle applicazioni native. Le applicazioni native possono (MAY) utilizzare qualsiasi opzione di reindirizzamento che si adatti meglio alle loro esigenze, tenendo conto dei dettagli di implementazione specifici della piattaforma.
7.1. Private-Use URI Scheme Redirection (Reindirizzamento con schema URI per uso privato)
Molte piattaforme informatiche mobili e desktop supportano la comunicazione tra app tramite URI consentendo alle app di registrare schemi URI per uso privato (talvolta colloquialmente chiamati "schemi URL personalizzati") come "com.example.app". Quando il browser o un'altra app tenta di caricare un URI con uno schema URI per uso privato, l'app che lo ha registrato viene avviata per gestire la richiesta.
Per eseguire una richiesta di autorizzazione OAuth 2.0 con un reindirizzamento con schema URI per uso privato, l'applicazione nativa avvia il browser con una richiesta di autorizzazione standard, ma una in cui l'URI di reindirizzamento utilizza uno schema URI per uso privato che ha registrato presso il sistema operativo.
Quando si sceglie uno schema URI da associare all'app, le app devono (MUST) utilizzare uno schema URI basato su un nome di dominio sotto il loro controllo, espresso in ordine inverso, come raccomandato dalla Sezione 3.8 di [RFC7595] per gli schemi URI per uso privato.
Ad esempio, un'app che controlla il nome di dominio "app.example.com" può utilizzare "com.example.app" come proprio schema. Alcuni server di autorizzazione assegnano identificatori client basati su nomi di dominio, ad esempio "client1234.usercontent.example.net", che possono anche essere utilizzati come nome di dominio per lo schema quando invertiti nello stesso modo. Uno schema come "myapp", tuttavia, non soddisferebbe questo requisito, poiché non è basato su un nome di dominio.
Quando ci sono più app dello stesso editore, è necessario prestare attenzione affinché ogni schema sia unico all'interno di quel gruppo. Su piattaforme che utilizzano identificatori di app basati su nomi di dominio in ordine inverso, tali identificatori possono essere riutilizzati come schema URI per uso privato per il reindirizzamento OAuth per aiutare a evitare questo problema.
Seguendo i requisiti della Sezione 3.2 di [RFC3986], poiché non esiste un'autorità di denominazione per i reindirizzamenti con schema URI per uso privato, solo una singola barra ("/") appare dopo il componente dello schema. Un esempio completo di URI di reindirizzamento che utilizza uno schema URI per uso privato è:
com.example.app:/oauth2redirect/example-provider
Quando il server di autorizzazione completa la richiesta, reindirizza all'URI di reindirizzamento del client come farebbe normalmente. Poiché l'URI di reindirizzamento utilizza uno schema URI per uso privato, ciò comporta che il sistema operativo avvii l'applicazione nativa, passando l'URI come parametro di avvio. Quindi, l'applicazione nativa utilizza l'elaborazione normale per la risposta di autorizzazione.
7.2. Claimed "https" Scheme URI Redirection (Reindirizzamento con URI schema "https" rivendicato)
Alcuni sistemi operativi consentono alle app di rivendicare URI con schema "https" [RFC7230] nei domini che controllano. Quando il browser incontra un URI rivendicato, invece che la pagina venga caricata nel browser, l'applicazione nativa viene avviata con l'URI fornito come parametro di avvio.
Tali URI possono essere utilizzati come URI di reindirizzamento dalle applicazioni native. Sono indistinguibili per il server di autorizzazione da un normale URI di reindirizzamento client basato sul web. Un esempio è:
https://app.example.com/oauth2redirect/example-provider
Poiché l'URI di reindirizzamento da solo non è sufficiente per distinguere i client di applicazioni native pubbliche dai client web confidenziali, è richiesto (REQUIRED) nella Sezione 8.4 che il tipo di client venga registrato durante la registrazione del client per consentire al server di determinare il tipo di client e agire di conseguenza.
Gli URI di reindirizzamento con schema "https" rivendicati dall'app presentano alcuni vantaggi rispetto ad altre opzioni di reindirizzamento per applicazioni native in quanto l'identità dell'app di destinazione è garantita al server di autorizzazione dal sistema operativo. Per questo motivo, le applicazioni native dovrebbero (SHOULD) utilizzarli rispetto alle altre opzioni quando possibile.
7.3. Loopback Interface Redirection (Reindirizzamento dell'interfaccia di loopback)
Le applicazioni native in grado di aprire una porta sull'interfaccia di rete di loopback senza necessitare di permessi speciali (tipicamente, quelle su sistemi operativi desktop) possono utilizzare l'interfaccia di loopback per ricevere il reindirizzamento OAuth.
Gli URI di reindirizzamento di loopback utilizzano lo schema "http" e sono costruiti con il letterale IP di loopback e la porta su cui il client è in ascolto.
Cioè, http://127.0.0.1:{port}/{path} per IPv4, e http://[::1]:{port}/{path} per IPv6. Un esempio di reindirizzamento utilizzando l'interfaccia di loopback IPv4 con una porta assegnata casualmente:
http://127.0.0.1:51004/oauth2redirect/example-provider
Un esempio di reindirizzamento utilizzando l'interfaccia di loopback IPv6 con una porta assegnata casualmente:
http://[::1]:61023/oauth2redirect/example-provider
Il server di autorizzazione deve (MUST) consentire di specificare qualsiasi porta al momento della richiesta per gli URI di reindirizzamento IP di loopback, per accomodare i client che ottengono una porta effimera disponibile dal sistema operativo al momento della richiesta.
I client non dovrebbero (SHOULD NOT) presumere che il dispositivo supporti una particolare versione del protocollo Internet. È raccomandato (RECOMMENDED) che i client tentino di collegarsi all'interfaccia di loopback utilizzando sia IPv4 che IPv6 e utilizzino quello disponibile.