OAuth2 è un protocollo di autenticazione che consente a applicazioni di terze parti di accedere a risorse protette per conto dell'utente. Include diversi ruoli (resource owner, client, resource server, authorization server) e flussi di autorizzazione (client credentials, password credentials, authorization code) per ottenere token di accesso. JWT è uno standard per la gestione dei token, che permette uno scambio sicuro di informazioni tra client e server.

1. OAuth2OAuth2OAuth2OAuth2 –––– Cos’ è?Cos’ è?Cos’ è?Cos’ è?
Meccanismo di autenticazione sicuro da parte di applicazioni terze
attraverso un componente detto Client che si interfaccia tra
l’utente che chiede l’accesso e l’ Authorization Server che lo
valida
1

2. 2
RuoliRuoliRuoliRuoli
● Resource Owner (R.O.): utente finale che richiede accesso
all’applicazione
● Client: Applicazione tramite la quale l’utente si interfaccia per chiedere
l’autenticazione
● Resource Server (R.S.): servizio protetto da autenticazione
● Authorization Server (A.S.): valida l’utente e in caso positivo gli
assegna un token tramite il quale accedere alle risorse protette

3. 3
ComponentiComponentiComponentiComponenti
● Client_id: stringa che identifica univocamente un client. L’A.S deve registrarlo nel
proprio sistema per poterlo riconoscere. E’ pubblico ed è noto al R.O.
● Client_secret: Come l’id A.S deve registrarlo. E’ segreto, lo conoscono solo A.S. e
client, non viene mai esposto via web.
● Access Token: stringa assegnata al client con la quale R.O. può accedere. Contiene
info che identificano utente e ruoli associate e una data di scadenza.
● Refresh Token: stringa assegnata al client da A.S. (non per tutti i grant type).
Contiene una data di scadenza maggiore dell’ access token con la quale il client può
aggiornare il token senza rieffettuare il login

4. 4
Flusso generaleFlusso generaleFlusso generaleFlusso generale

5. 5
Flusso generaleFlusso generaleFlusso generaleFlusso generale
1. l’utente dà al client il tipo di grant con la quale vuole accedere;
2. il client fornisce all’A.S il tipo di grant oltre alle credenziali del
client e utente. Se la validazione va a buon fine A.S risponde un
token.
3. il client con il token appena ricevuto può accedere alle risorse
protette

6. 6
Tipi di GrantTipi di GrantTipi di GrantTipi di Grant
● Client Credentials: il flusso non prevede una login. E’ sufficiente inviare id
e secret del client per ottenere il token. E’ usato quando non è prevista
interazione con utente
● Password Credentials: in questo flusso, per ottenere il token dall’A.S., il
client deve fornire oltre al suo id e secret anche username e password fornite
dall’utente
● Authorization Code: prima di accedere alla login form, A.S. reindirizza
l’utente in una pagina in cui gli si chiede conferma di autorizzazione. In caso
positivo il flusso continua e l’A.S. fornisce all’utente un authorization code
che gli servirà per scambiarlo con il token

7. 7
Flusso ClientFlusso ClientFlusso ClientFlusso Client CredentialsCredentialsCredentialsCredentials
Il client dà al A.S il proprio id e secret, se validi gli sarà restituito l’
access token. Questo tipo di grant non prevede refresh token

8. 8
Flusso Password GrantFlusso Password GrantFlusso Password GrantFlusso Password Grant TypeTypeTypeType

9. 9
Flusso Password GrantFlusso Password GrantFlusso Password GrantFlusso Password Grant TypeTypeTypeType
● A: R.O. fornisce al client username e password
● B: il client invia all’A.S le credenziali fornite dall’ utente oltre alle proprie
(encodate in base64 nell’ header Authorization Basic della request
● C: se A.S. valida l’utente restituisce al client un access e un refresh token
Esempio di response
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
}
Esempio di request
POST localhost:80808/token
Host: www.oauth2-example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=<username>&password=<password>

10. 10
FlussoFlussoFlussoFlusso AuthorizationAuthorizationAuthorizationAuthorization CodeCodeCodeCode

11. 11
FlussoFlussoFlussoFlusso AuthorizationAuthorizationAuthorizationAuthorization CodeCodeCodeCode
● A: il client reindirizza l’utente all’A.S. passandogli il proprio id e una redirect uri
fornita dall’ utente
● B: A.S. autentica l’utente con una login form e gli chiede consenso ad accedere
● C: se l’utente ha dato l’ok A.S lo reindirizza alla redirect uri data al punto A
includendo un authorization code
● D: il client invia la richiesta di token all’A.S passandogli authorization code
fornito al punto C e la redirect Uri
● E: se auth. Code e redirect uri sono validi l’A.S gli restituisce una access token e
opzionalmente un refresh token

12. 12
AccessAccessAccessAccess TokenTokenTokenToken
● è una stringa generata dall’A.S con la quale il R.S è in grado di
validare l’autenticazione
● deve contenere una data di scadenza oltre la quale il token non è più
valido
● può contenere informazioni dell’ utente (per esempio username e
ruoli associati in caso di un sistema RBAC)

13. 13
RefreshRefreshRefreshRefresh TokenTokenTokenToken
● è una stringa generata dall’A.S avente una data di scadenza
maggiore dell’ access token
● È previsto solo per i flussi authorization code e password credentials
● Quando l’access token scade, si chiama un refresh end point con il
quale l’A.S aggiorna l’access token e gli dà un nuovo o lo stesso
refresh token
● Se anche il refresh token è scaduto l’A.S reindirizza il client alla
pagina di login

14. 14
JWT (JWT (JWT (JWT (JsonJsonJsonJson WebWebWebWeb TokenTokenTokenToken))))
● è lo standard al momento più usato per i sistemi di autenticazione
definito dalla IETF (rfc7519)
● Include informazioni (dette Claims) in formato Json
● È scritto secondo un algoritmo di cifratura (HMAC, RSA, EDCSA)
che ne identifica la cosiddetta signature consentendo una scambio
sicuro tra due controparti (nel caso dell’ OAuth2 tra client e A.S.)
● Nelle http request viene passato come Authorization Bearer nei
parametri di header

15. 15
JWT: StrutturaJWT: StrutturaJWT: StrutturaJWT: Struttura
È formato da tre parti separate da punto header.payload.signature
● Header: contiene informazioni basi, quali l’algoritmo di cifratura ed
il tipo di token.
● Payload: contiene i claims, alcuni sono standard ed altri custom
● Signature: è una stringa codificata secondo l’algoritmo usato
costruita con header, payload ed una chiave privata fornita all’
algoritmo di cifratura

16. 16
JWT: Esempio diJWT: Esempio diJWT: Esempio diJWT: Esempio di headerheaderheaderheader
{
"alg": "RS256",
"typ": "JWT"
}
Esempio di Jwt di tipo base creato
con algoritmo RS256

17. 17
JWT: Esempio diJWT: Esempio diJWT: Esempio diJWT: Esempio di payloadpayloadpayloadpayload
{
"aud": "123456GFW",
"exp": 1559832749,
"iss": "Auth_server_name",
"sub": "test_user44",
"ExtraClaims": {
"userid": 14,
"username": "test_user44",
"permissions": "ADMIN"
}
}
Il payload contiene alcuni standard claims definiti dalla specifica:
● Aud: client_id dell’ app che chiede il token
● Exp: data di scadenza espressa in unix timestamp
● Iss: nome dell’ applicazione che ha rilasciato il token (A.S.)
● Sub: il soggetto identificato, di solito è lo username
● ExtraClaims: sono i claims personalizzati e totalmente arbitrati

18. 18
JWT: Stringa di esempioJWT: Stringa di esempioJWT: Stringa di esempioJWT: Stringa di esempio
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJhYmNkZWYxOEYy
NCIsImV4cCI6MTU1OTgzMzMxNSwiaXNzIjoiQXV0aF9TZXJ2ZXJfbmFt
ZSIsInN1YiI6InRlc3RfdXNlcjQ0IiwiRXh0cmFDbGFpbXMiOnsidXNlcmlkIj
oxNCwidXNlcm5hbWUiOiJ0ZXN0X3VzZXI0NCIsInBlcm1pc3Npb25zIjoi
QURNSU4ifX0.a6K84ZcQP474aUR0yWH_BAdJcbqMiiDFz56QZluZ-
k8qjkjlNLRyoYFfTCvW3P2dAJ5lo1A4Nrjo3Bv46IAHUl6Ok_1eIWIDxNSD
4Ii6PJR66Ji2mmX2D9az5NahsJ31UcHlBW1Vme3FAgPjBvlH_lJQnTpgrAn
d2BG-LRIc1JgwRyW0bSS3ucFeI9r_Ydez_CMF6GpP-
YaYpumc4lfDrLFYpy_Vkph-
ZXOrQ26LYI4mkLuIDMmDV1ybbN8n1i8PaMp2CtcsTY2usJdopHrkugWb
AK-OxzCgdX7wFvcTuzdji_EfUlO-iR6AdUmVxQg7zGSoKlcOVQSS-
jDR3jBk8A

19. 19
RSARSARSARSA
● Specifica di crittografia definita dalla IETF (rfc8017)
● È un algoritmo a chiave asimmetrica. Usa una coppia di
chiavi privata/pubblica. La privata è usata da chi genera il
messaggio criptato (signature) che può essere validato solo da
chi detiene la chiave pubblica
● Usa gli algoritmi di hash SHA-2
● chi ha la chiave pubblica può solo validare il messaggio, ma
non può crearne alcuno.

20. 20
HS256HS256HS256HS256
● È un algoritmo a chiave simmetrica. La stessa chiave viene
usata sia per creare che per validare il messaggio
● usa la specifica HMAC (rfc2104)

21. 21
● https://tools.ietf.org/html/rfc6749
● https://tools.ietf.org/html/rfc7519
● https://jwt.io/introduction/
● https://tools.ietf.org/html/rfc8017
AndreaAndreaAndreaAndrea ArestaArestaArestaAresta
SoftwareSoftwareSoftwareSoftware EngineerEngineerEngineerEngineer
RiferimentiRiferimentiRiferimentiRiferimenti