Google Auth Mechanism Emanuel Di Nardo m

Quattro meccanismi di accesso: 1. OAuth 2.0 (Web e Installed) 2. OAuth 1.0 (deprecato) 3. OpenID (Web) 4. Hybrid Protocol (Web)

OAuth 2.0

Permette l’accesso ad API private Fornisce sicurezza e protezione per gli utenti L’applicazione di terze parti non può conoscere i dati inseriti in fase di login Autenticazione sicura fornita da Google Utilizzo di token di sicurezza

Utilizzo: Registrare l’applicazione su Google APIs Console e scegliere i servizi da utilizzare

Generazione OAuth ID Verranno generate chiavi univoche per l’utilizzo dei servizi

Effettuare il login/autorizzazione tramite il seguente url: Aggiungendo i seguenti parametri con metodo HTTP GET:

Il parametro ‘scope’ definisce a quali informazioni stiamo cercando di accedere: Lo scope è indicato nella documentazione della risorse a cui si tenta di accedere (calendar/gmail/contacts/ecc...) Es. informazioni account Informazioni sull’intero account: Informazioni sull’indirizzo Possono essere inseriti entrambi!

Gli altri parametri variano in base al tipo di applicazione che stiamo costruendo. Web server: response_type: code; redirect_uri: specificato nella generazione dell’OAuth ID; Client-side: response_type: token; redirect_uri: specificato nella generazione dell’OAuth ID; Installed app: reponse_type: code; redirect_uri: urn:ietf:wg:oauth:2.0:oob: codice restituito nel titolo della pagina html l’applicazione rimane in ascolto su una porta di rete, devono essere permesse le connessioni in entrata (attenzione ai firewall)

Dopo l’accesso verrà mostrata una finestra di autorizzazione per l’utente

Nel caso di response_type: code dovrà essere generata una nuova richiesta per avere il token di accesso: Richiesta di tipo POST con parametri: La risposta sarà un JSON come il seguente:

Per effettuare una richiesta specifica dobbiamo consultare la documentazione della risorsa desiderata. Vengono utilizzati solitamente i metodi HTTP [GET, POST, DELETE] Es.: Richiesta informazioni utente: AzqT3Zg Richiesta Google Calendar: _token=1/fFBGRNJru1FQd44AzqT3Zg AzqT3Zg _token=1/fFBGRNJru1FQd44AzqT3Zg

Alla scadenza del token expires_in dobbiamo richiederne uno nuovo, utilizziamo la chiave refresh_token Nuova richiesta HTTP POST:

Problema di sicurezza client-side: I token devono essere validati! Aggiungere il parametro access_token con il valore appena ricevuto al seguente URL: In risposta avremo un nuovo JSON: La verifica è valida solo se audience corrisponde al proprio client_id

In sintesi:

Materiale disponibile al seguente indirizzo: