3. Implementation Note (Nota di implementazione)

3. Implementation Note (Nota di implementazione)

OAuth 2.0 consente flessibilità di distribuzione rispetto allo stile dei token di accesso. I token di accesso possono essere autonomi in modo che un resource server (server di risorse) non necessiti di ulteriori interazioni con un server di autorizzazione che emette questi token per prendere una decisione di autorizzazione del client che richiede l'accesso a una risorsa protetta. Una progettazione di sistema può, tuttavia, utilizzare invece token di accesso che sono handle che fanno riferimento ai dati di autorizzazione memorizzati nel server di autorizzazione. Ciò richiede di conseguenza che un server di risorse emetta una richiesta al rispettivo server di autorizzazione per recuperare il contenuto del token di accesso ogni volta che un client presenta un token di accesso.

Sebbene queste non siano le uniche opzioni, illustrano le implicazioni per la revoca. In quest'ultimo caso, il server di autorizzazione è in grado di revocare un token di accesso precedentemente rilasciato a un client quando il server di risorse inoltra un token di accesso ricevuto. Nel primo caso, può essere utilizzata una certa interazione backend (attualmente non standardizzata) tra il server di autorizzazione e il server di risorse quando si desidera la revoca immediata del token di accesso. Un'altra alternativa di progettazione consiste nell'emettere token di accesso di breve durata, che possono essere aggiornati in qualsiasi momento utilizzando i corrispondenti token di aggiornamento. Ciò consente al server di autorizzazione di imporre un limite al tempo revocato quando i token di accesso sono in uso.

Quale approccio alla revoca del token verrà scelto dipenderà dalla progettazione complessiva del sistema e dall'analisi dei rischi del fornitore di servizi applicativi. Il costo della revoca in termini di stato richiesto e sovraccarico di comunicazione è in definitiva il risultato delle proprietà di sicurezza desiderate.