Chiarimento: app mobile = app nativa
Come affermato in altri commenti e in alcune fonti online, l'implicito sembra una scelta naturale per le app mobili, tuttavia la soluzione migliore non è sempre chiara (e in effetti implicita non è raccomandata per i motivi discussi di seguito).
Best practice per OAuth2 dell'app nativa
Qualunque sia l'approccio scelto (ci sono alcuni compromessi da considerare), dovresti prestare attenzione alle migliori pratiche come delineato qui per le app native che utilizzano OAuth2: https://tools.ietf.org/html/rfc8252
Considera le seguenti opzioni
Implicito
Dovrei usare implicit?
Per citare dalla Sezione 8.2 https://tools.ietf.org/html/rfc8252#section-8.2
Il flusso di autorizzazione di concessione implicita OAuth 2.0 (definito nella sezione 4.2 di OAuth 2.0 [RFC6749]) generalmente funziona con la pratica di eseguire la richiesta di autorizzazione nel browser e ricevere la risposta di autorizzazione tramite comunicazione inter-app basata su URI.
Tuttavia, poiché il flusso implicito non può essere protetto da PKCE [RFC7636] (richiesto nella sezione 8.1), l'uso del flusso implicito con app native NON È RACCOMANDATO .
Anche i token di accesso concessi tramite il flusso implicito non possono essere aggiornati senza l'interazione dell'utente, rendendo il flusso di concessione del codice di autorizzazione, che può emettere token di aggiornamento, l'opzione più pratica per le autorizzazioni delle app native che richiedono l'aggiornamento dei token di accesso.
codice di autorizzazione
Se si utilizza il codice di autorizzazione, un approccio potrebbe essere quello di eseguire il proxy tramite il proprio componente del server Web che arricchisce le richieste di token con il segreto del client per evitare di memorizzarlo sull'app distribuita sui dispositivi.
Estratto di seguito da: https://dev.fitbit.com/docs/oauth2/
Il flusso di concessione del codice di autorizzazione è consigliato per le applicazioni che dispongono di un servizio Web. Questo flusso richiede la comunicazione da server a server utilizzando il segreto client di un'applicazione.
Nota: non inserire mai il segreto client nel codice distribuito, come le app scaricate tramite un app store o JavaScript lato client.
Le applicazioni che non dispongono di un servizio Web devono utilizzare il flusso di concessione implicita.
Conclusione
La decisione finale dovrebbe tenere conto della tua esperienza utente desiderata ma anche della tua propensione al rischio dopo aver effettuato un'adeguata valutazione del rischio degli approcci selezionati e una migliore comprensione delle implicazioni.
Un'ottima lettura è qui https://auth0.com/blog/oauth-2-best-practices-for-native-apps/
Un altro è https://www.oauth.com/oauth2-servers/oauth-native-apps/ che afferma
L'attuale best practice del settore consiste nell'utilizzare il flusso di autorizzazione omettendo il segreto del client e utilizzare un agente utente esterno per completare il flusso. Un agente utente esterno è in genere il browser nativo del dispositivo (con un dominio di sicurezza separato dall'app nativa) in modo che l'app non possa accedere all'archivio dei cookie o ispezionare o modificare il contenuto della pagina all'interno del browser.
Considerazione PKCE
Dovresti anche considerare PKCE che è descritto qui https://www.oauth.com/oauth2-servers/pkce/
In particolare, se stai implementando anche il server di autorizzazione, https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ afferma che dovresti
- Consenti ai client di registrare schemi URL personalizzati per i loro URL di reindirizzamento.
- Supporta URL di reindirizzamento IP di loopback con numeri di porta arbitrari per supportare le app desktop.
- Non dare per scontato che le app native possano mantenere un segreto. Richiedi a tutte le app di dichiarare se sono pubbliche o riservate e rilascia i segreti del client solo alle app riservate.
- Supportare l'estensione PKCE e richiedere che i client pubblici la utilizzino.
- Tenta di rilevare quando l'interfaccia di autorizzazione è incorporata nella visualizzazione Web di un'app nativa, invece di essere avviata in un browser di sistema, e rifiuta tali richieste.
Considerazione sulle visualizzazioni web
Ci sono molti esempi in natura che utilizzano le visualizzazioni Web, ad esempio un agente utente incorporato, ma questo approccio dovrebbe essere evitato (specialmente quando l'app non è di prima parte) e in alcuni casi potrebbe essere vietato l'utilizzo di un'API come estratto sotto da qui dimostra
Qualsiasi tentativo di incorporare la pagina di autenticazione OAuth 2.0 comporterà il divieto della tua applicazione dall'API Fitbit.
Per motivi di sicurezza, la pagina di autorizzazione OAuth 2.0 deve essere presentata in una vista browser dedicata. Gli utenti Fitbit possono confermare che si stanno autenticando con il sito Fitbit.com autentico solo se dispongono degli strumenti forniti dal browser, come la barra degli URL e le informazioni sul certificato Transport Layer Security (TLS).
Per le applicazioni native, ciò significa che la pagina di autorizzazione deve essere aperta nel browser predefinito. Le applicazioni native possono utilizzare schemi URL personalizzati come URI di reindirizzamento per reindirizzare l'utente dal browser all'applicazione che richiede l'autorizzazione.
Le applicazioni iOS possono utilizzare la classe SFSafariViewController invece del passaggio dell'app a Safari. L'uso della classe WKWebView o UIWebView è vietato.
Le applicazioni Android possono utilizzare le schede personalizzate di Chrome invece del passaggio delle app al browser predefinito. L'uso di WebView è vietato.
Per chiarire ulteriormente, ecco una citazione da questa sezione di una precedente bozza del collegamento alle migliori pratiche fornito sopra
Gli user-agent incorporati, comunemente implementati con le visualizzazioni Web, sono un metodo alternativo per autorizzare le app native. Tuttavia, per definizione non sono sicuri per l'uso da parte di terzi. Coinvolgono l'utente che accede con le proprie credenziali di accesso complete, solo per ridurli a credenziali OAuth meno potenti.
Anche se utilizzati da app affidabili di prima parte, gli user-agent incorporati violano il principio del privilegio minimo ottenendo credenziali più potenti di quelle necessarie, aumentando potenzialmente la superficie di attacco.
Nelle tipiche implementazioni basate sulla visualizzazione Web di agenti utente incorporati, l'applicazione host può: registrare ogni battitura immessa nel modulo per acquisire nomi utente e password; invia automaticamente i moduli e ignora il consenso dell'utente; copiare i cookie di sessione e utilizzarli per eseguire azioni autenticate come utente.
Incoraggiare gli utenti a inserire le credenziali in una visualizzazione Web incorporata senza la solita barra degli indirizzi e altre caratteristiche di identità dei browser rende impossibile per l'utente sapere se stanno accedendo al sito legittimo e, anche quando lo sono, li addestra che va bene inserire le credenziali senza prima convalidare il sito.
A parte i problemi di sicurezza, le visualizzazioni Web non condividono lo stato di autenticazione con altre app o il browser di sistema, richiedendo all'utente di accedere per ogni richiesta di autorizzazione e portando a un'esperienza utente scadente.
Per quanto sopra, l'uso di user-agent incorporati NON È RACCOMANDATO, tranne quando un'app di prima parte affidabile funge da agente utente esterno per altre app o fornisce Single Sign-On per più app di prima parte.
I server di autorizzazione DOVREBBERO prendere in considerazione l'adozione di misure per rilevare e bloccare gli accessi tramite agenti utente incorporati che non sono i propri, ove possibile.
Alcuni punti interessanti vengono sollevati anche qui: /security/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the- un