Outh 2.0 è un protocollo di autorizzazione e viene utilizzato per fornire l’accesso ad un insieme di risorse, come ad esempio WebApi.
OAuth 2.0 fornisce l’accesso e limita le azioni di ciò che l’app client può eseguire sulle risorse per conto dell’utente, senza mai condividere le sue credenziali.
Il funzionamento di Outh 2.0 è basata sul concetto di access token, che contiene le informazioni necessarie per definire l’autorizzazione ad accedere a risorse per conto dell’utente finale. Una buona pratica è quella di indicare una scadenza per l’access token, che dovrà quindi essere rigenerato per poter garantire nuovamente l’accesso alle risorse.
Di fatto, non viene definito il formato che dovrà avere il token, ma molto spesso viene utilizzato il formato JWT (JSON Web Token).
Prima di addentrarci all’interno del mondo di OAuth 2.0, un po di concetti base.
Nell’architettura di OAuth 2.0 entrano in gioco i seguenti componenti:
- Client: il sistema che richiede l’accesso alle risorse protette
- Authorization Server: è il server che riceve le richieste dal client per l’emissione dell’access token e lo emette dopo l’autententicazione ed il consenso da del resource owner. E’ composto da due due endpoint: quello che consente di effettuare l’autenticazione vera e propria (iterattiva e con il consenso dell’utente) ed quello del token che è coinvolto nell’iterazione machine-to-machine
- Resource Owner: l’utente o il sistema che detiene le risorse protette e che può gestirne i permessi
- Resource Server: è il server che protegge le risorse e che riceve l’access token. Il suo compito è quello di verificare l’access token e rispondere con le risorse appropriate
Spesso parlando di autorizzazione/autenticazione ci si imbatte sul concetto di Claim e di Scope.
- i claims sono affermazioni che un soggetto (ad esempio un utente o un server di autorizzazione) fa su se stesso o su un altro soggetto.
- gli scopes sono gruppi di claims.
I Claims si trovano all’interno del token e lo integrano aggiungendo informazioni. Ad esempio, un ID Token è composto da alcuni claim contenenti informazioni sull’utente, come il suo nome e cognome, e-mail o indirizzo. I Claims possono anche contenere informazioni sul client o sul token stesso, ad esempio chi lo ha emesso o qual è il suo audience.
Gli scopes sono un raggruppamento logico dei claims: ad esempio lo scope profile. Consentendo l’accesso a questo scope è possibile accedere ai seguenti claims:
- name
- family_name
- given_name
- middle_name
- nickname
- preferred_username
- profile_picture
- website, gender
- birthdate
- zone_info
- locale
- updated_at
A questo punto risulta evidente che la richiesta dello scope profile è molto piu semplice ed immediata che chiedere l’accesso al singolo claim. E’ comunque da notare che la richiesta di uno scope invece dei claims fornisce un minore controllo sul contenuto del token e può essere insufficiente per alcune configurazioni.
Inoltre, gli scopes sono spesso un meccanismo per limitare l’accesso del client alle risorse dell’utente. Il client può richiedere, ad esempio, lo scope orders_read
, il che significa che il token emesso gli consentirà solo di interrogare gli endpoint degli ordini e di non apportare modifiche.
Un’altro modo di considerare gli scopes ed i claims è che gli scopes siano posizionati a livello di client. Il client richiede il consenso per un particolare scope, e l’Authorization Server può limitare quali client possono accedere ad un particolare scope.