Spiegazione protocollo Open Authorization OAuth 2.0

Vi parliamo adesso del protocollo di sicurezza Open Authorization che è appunto la contrazione di OAuth. Per la precisione al momento siamo alla versione 2.0.

OAuth è un protocollo universale ossia compatibile con tutti i dispositivi desktop, web e mobile.

Si parla di questo protocollo dal 2006 quanod Blaine Cook lo ideo per Twitter OpenID in versione Open Source. Mentre Google , Yahoo, MSN utuilizzavano protocolli dedicati.

Attualmente però tutti stanno andando verso questa piattaforma.

Principio di Funzionamento di OAuth

L’idea che sta alla base di questo protocollo è la possibilità di autorizzare terze parti per la gestione di documenti o applicazioni senza lo scambio di password. Per questo motivo OAuth nasce proprio dal progetto SAML. Che si basava proprio su questo principio. Ossia la necessità di una sola autenticazione. Ovviamente esiste la possibilità di revoca di tale autorizzazione

Attori Open Authorization

Gli autori di questo tipo di protocollo sono tre.

• Server E’ il luogo dove sono le risorse
• Utente ossia la persona che garantisce l’accesso alle risorse
• Client richiede l’accesso alle risorse protette.

Con la versione 2.0 è stata aggiunta la figura del Server Mediatore che tipicamente è rappresentato dal browser nel quale viene fatta l’autenticazione.

La particolare novità di questo protocollo rispetto ai precedenti è che viene data l’autorizzazione solamente alle risorse di cui realmente si necessita.
Ovviamente il tutto è improntato alla semplicità.

Non esiste nemmeno il concetto di password tradizionale di accesso come visto fino a poco tempo fa. Con le Oauth si introduce infatti il concetto di ID token.

I componenti dell’ID Token sono

• OpenID subject ossia che vi identifica come user
• iss che identifica l’emittente per la risposta. E’ un url che può essere anche https con numero di porta.
• aud contiene le client_id OAuth 2.0 per identificare appunto il destinatario
• exp Ora di scadenza o dopo che l’ID token NON DEVE essere accettato per l’elaborazione.
• iat Obbligatorio. Ora in cui è stato rilasciato. Il suo valore è un numero JSON che rappresenta il numero di secondi da 1970-01-01T0: 0: 0Z misurata in UTC fino alla data / ora.
• nonce Valore stringa utilizzato per associare una sessione client con un ID token, e per mitigare gli attacchi replay. Il valore viene passato attraverso non modificato dalla richiesta di autenticazione per l’ID del token. Se presente nel ID token, i clienti devono verificare che il nonce sia uguale al valore al parametro inviato nella richiesta di autenticazione. Se presente nella richiesta di autenticazione, i server autorizzazione deve includere un nonce nel ID token con il valore della domanda che deve corrispondere al  valore nonce inviato nella richiesta di autenticazione.
• acr  OPZIONALE. Stringa che specifica un valore di riferimento di classe autenticazione contesto che identifica la classe del contesto di autenticazione che l’autenticazione eseguita soddisfatti. Il valore “0” indica l’autenticazione con l’utente finale che non ha soddisfatto i requisiti della norma ISO / IEC 29115 .

Questi alcuni dei parametri principali OAuth2

I taken id hanno si identificano con JWS e sono file in formato Json una possibile implementazione potrebbe essere

{
 "iss": "https://esempio.it",
 "sub": "alice",
 "aud": "client-1234",
 "nonce": "n-0S6_WzA2Mj",
 "exp": 1311281970,
 "iat": 1311280970,
 "auth_time": 1311280969,
 "acr": "urn:mace:incommon:iap:argento"
 }

Il taken può essere richiesto essenzialmente in tre modi

• Autorizzazione di codice con flusso. E’ un’autenticazione di tipo server side.  In questo caso l’applicazione client viene redirezionata all’authorization endpoint del provider.  Generalmente viene fatto in due passi. Autenticazione per il consenso e una seconda richiesta per recuperare il token-id attraverso un back channel.
• In Maniera implicita . Ossia si tratta più che altro di applicazioni  client side. Ossia tramite applicazioni via Browser . Dove il token viene fornito con il reindirizzamento. E’ un autenticazione meno sicura rispetto alla precedente. Particolarmente vulnerabile agli attacchi di tipo XSS Cross Scripting.
• Combinazione server side  client. Si tratta piu’ che altro di combinazioni dedicate dei due modi sopra elencati. Scritti per applicazioni dedicate.

Ora che sappiamo cosa contiene un token access vediamo come sia possibile reperirlo. Secondo uno schema molto generale.

• Il reosurce Owner invia i permessi ( authorization gran ) al client. Questi possono essere di 4 tipi authorization code, implicit, resource owner password credentials e client credentials.
• Il Client con i permessi ottenuti richiede un token access all’authorization server.
• L’authorization server convalida il client e relativo permesso. In caso di esito positivo invia un token access.
• il resource server valida il token , se valido invia quanto richiesto dal client.