4. Overview (Panoramica)
Per autorizzare gli utenti nelle applicazioni native, la migliore pratica corrente consiste nell'eseguire la richiesta di autorizzazione OAuth in un user-agent esterno (External User-Agent) (tipicamente il browser) piuttosto che in un user-agent incorporato (Embedded User-Agent) (come quello implementato con web-view).
In precedenza, era comune che le applicazioni native utilizzassero user-agent incorporati (comunemente implementati con web-view) per le richieste di autorizzazione OAuth. Tale approccio presenta molti svantaggi, tra cui la possibilità per l'app host di copiare le credenziali utente e i cookie, nonché la necessità per l'utente di autenticarsi da zero in ogni app. Vedere la Sezione 8.12 per un'analisi più approfondita degli svantaggi dell'utilizzo di user-agent incorporati per OAuth.
Le richieste di autorizzazione delle applicazioni native che utilizzano il browser sono più sicure e possono sfruttare lo stato di autenticazione dell'utente. La possibilità di utilizzare la sessione di autenticazione esistente nel browser abilita il single sign-on, poiché gli utenti non devono autenticarsi al server di autorizzazione ogni volta che utilizzano una nuova app (a meno che non sia richiesto dalla politica del server di autorizzazione).
Il supporto dei flussi di autorizzazione tra un'applicazione nativa e il browser è possibile senza modificare il protocollo OAuth stesso, poiché la richiesta e la risposta di autorizzazione OAuth sono già definite in termini di URI. Ciò include gli URI che possono essere utilizzati per la comunicazione tra app. Alcune implementazioni di server OAuth che presumono che tutti i client siano client web confidenziali dovranno aggiungere una comprensione dei client di applicazioni native pubbliche e dei tipi di URI di reindirizzamento che utilizzano per supportare questa migliore pratica.
4.1. Authorization Flow for Native Apps Using the Browser (Flusso di autorizzazione per applicazioni native utilizzando il browser)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| User Device |
| |
| +--------------------------+ | (5) Authorization +---------------+
| | | | Code | |
| | Client App |---------------------->| Token |
| | |<----------------------| Endpoint |
| +--------------------------+ | (6) Access Token, | |
| | ^ | Refresh Token +---------------+
| | | |
| | | |
| | (1) | (4) |
| | Authorizat- | Authoriza- |
| | ion Request | tion Code |
| | | |
| | | |
| v | |
| +---------------------------+ | (2) Authorization +---------------+
| | | | Request | |
| | Browser |--------------------->| Authorization |
| | |<---------------------| Endpoint |
| +---------------------------+ | (3) Authorization | |
| | Code +---------------+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
Figura 1: Autorizzazione dell'applicazione nativa tramite un user-agent esterno
La Figura 1 illustra l'interazione tra un'applicazione nativa e il browser per autorizzare l'utente.
(1) L'app client apre una scheda del browser con la richiesta di autorizzazione.
(2) L'endpoint di autorizzazione riceve la richiesta di autorizzazione, autentica l'utente e ottiene l'autorizzazione. L'autenticazione dell'utente può comportare il concatenamento ad altri sistemi di autenticazione.
(3) Il server di autorizzazione emette un codice di autorizzazione all'URI di reindirizzamento.
(4) Il client riceve il codice di autorizzazione dall'URI di reindirizzamento.
(5) L'app client presenta il codice di autorizzazione all'endpoint del token.
(6) L'endpoint del token convalida il codice di autorizzazione ed emette i token richiesti.