Come dovrebbero i fornitori di risorse convalidare i token OAuth2?

Question

Come dovrebbero i fornitori di risorse convalidare i token OAuth2?

#1 da (5 voti)

9

I fornitori di risorse forniscono spesso accesso in lettura e scrittura alle risorse.

Pertanto, il fornitore di risorse dovrebbe non solo convalidare il token (è scaduto? è revocato? è valido? contiene l'ambito richiesto?), dovrebbero anche controllare i privilegi del token (usa XY avere privilegi sufficienti per leggere o scrivere risorsa ZY?).

Fino ad ora ho utilizzato il seguente flusso di lavoro:

Il client riceve un token di accesso tramite la concessione del codice OAuth2.
Il Cliente inoltra una richiesta per conto dell'utente ad es. %codice%
Il Servizio risorse (chiamiamolo Post utente ) convalida il token effettuando una richiesta al server di autorizzazione, confermando che il token è valido. Inoltre, il server di autorizzazione passa i metadati come la data di scadenza del token, il pubblico del token, gli ambiti del token e l'oggetto del token (ad esempio, Utente XY)
Il Servizio risorse ora convalida che il soggetto (ad esempio Utente XY) è autorizzato / autorizzato a eseguire la richiesta. Ad esempio controllando un elenco di controllo di accesso o simile. Ad esempio: supponiamo che l'utente XY desideri aggiornare un post dell'utente da parte dell'utente AB. Ad esempio, questo sarebbe disabilitato dalla Lista controllo accessi.
Se la convalida supera, il server di risorse esegue la richiesta.

Questo è un modo valido di fare le cose o sto aprendo i vettori di attacco? Va bene che il Resource Server assuma che l'argomento del token sia quello da considerare la richiesta di autorizzazione? Ci sono forse buone pratiche o standard per risolvere questo?

Al momento sono confuso, perché ho letto che OAuth2 è solo una delega, non un'autorizzazione né un'autenticazione e che i client non dovrebbero assumere assunzioni implicite come "il token XY appartiene all'utente AB, quindi l'utente AB è autenticato" .

Qualsiasi aiuto è gradito.

authentication oauth authorization

posta machete 29.12.2015 - 14:07

fonte

1 risposta

Leggi altre domande sui tag authentication oauth authorization

Esistono altri modi per crittografare file diversi da TrueCrypt e BitLocker [chiuso] Sessione e ID sessione SSL

score 5 · Accepted Answer

RFC 6750 , Il framework di autorizzazione OAuth 2.0: utilizzo di token bearer , Sezione 5: Considerazioni sulla sicurezza illustra alcuni dei problemi relativi all'uso dei token al portatore. Dalla sezione 5.2:

5.2. Threat Mitigation

A large range of threats can be mitigated by protecting the contents of the token by using a digital signature or a Message Authentication Code (MAC). Alternatively, a bearer token can contain a reference to authorization information, rather than encoding the information directly. Such references MUST be infeasible for an attacker to guess; using a reference may require an extra interaction between a server and the token issuer to resolve the reference to the authorization information. The mechanics of such an interaction are not defined by this specification.

Nel passaggio 3 del flusso di lavoro si descrive il servizio risorse che richiede il servizio di autorizzazione se il token è valido. Questo è un esempio di utilizzo di un riferimento per risolvere le informazioni di autorizzazione. Tuttavia, il passaggio 4 ha il server delle risorse che convalida l'oggetto (ad esempio UserXY). Questo è un esempio di autorizzazione di codifica nel token stesso. Questo approccio ibrido non è un problema, ma puoi semplificare la progettazione scegliendo l'uno o l'altro.

Inoltre, invece di usare UserXY di un token soggetto per conferire tutte le autorizzazioni di un utente a un singolo token, potrebbe essere meglio usare il principio del privilegio minimo qui e fare in modo che il server di autorizzazione inserisca autorizzazioni specifiche (ad esempio, leggi l'email UserXY, componi messaggi UserXY) piuttosto che dare accesso a qualsiasi cosa UserXY possa fare.