OAuthv2 token di accesso e server di risorse

Question

OAuthv2 token di accesso e server di risorse

#1 da (1 voti)

2

Nella concessione dell'autorizzazione OAuthv2 , un'app client "autentica se stesso contro un" server di autenticazione "e riceve un" token di accesso "per accedere alle risorse che vivono in un" server delle risorse ”.

Le mie preoccupazioni:

Come fa il server delle risorse a sapere che il token di accesso è valido (non falsificato o scaduto)? Esiste qualche comunicazione di base sottostante tra il server delle risorse e il server di autenticazione?
In che modo il server delle risorse conosce l'ambito del token di accesso (lettura o scrittura)? Ad esempio, forse quando l'app client è stata autorizzata, l'utente l'ha autorizzato solo per SOLO LETTURA, ma ora l'app client sta tentando di modificare le risorse. In che modo il server delle risorse protegge da questo?
Ovviamente nel mondo reale ci devono essere ruoli / ambiti più fini oltre che READ e WRITE. Ad esempio, un servizio web potrebbe dover consentire le SCRITTURE a determinati utenti / client, ma solo per determinate risorse o risorse nelle giuste condizioni. In che modo gli ambiti OAuthv2 integrati vengono associati a ruoli / autorizzazioni specifici dell'app?

authentication authorization oauth2

posta smeeb 14.09.2015 - 21:21

fonte

1 risposta

Leggi altre domande sui tag authentication authorization oauth2

Processo per il trasferimento di compiti TFS tra utenti? Accesso ai cookie di applicazioni incrociate

score 1 · Answer 1

1) Il server di risorse deve ricontrollare con il server di autorizzazione per assicurarsi che il token sia ancora valido. Questo di solito implica fare una richiesta e ottenere una risposta.

2) Una delle proprietà di un token di accesso OAuth2 è l'ambito che ha ottenuto quando Autorizzazione Server lo ha concesso. Di solito, quando il server di risorse viene controllato, il server di autorizzazione includerà l'ambito nella risposta.

3) Le specifiche OAuth2 non specificano gli ambiti, quindi possono essere qualsiasi cosa tu voglia. Ad esempio, la specifica di Open Id Connect indica una serie di ambiti specifici: ["telefono", "offline_access", "indirizzo", "email", "openid", "utente", "profilo"]. Questi ambiti hanno un significato specifico in Open ID Connect, ma non sono nominati nella specifica OAuth2.

Se si desidera definire gli ambiti READ, WRITE, TRANSMUTE, PERCOLATE, FINDLE, SPLINE o qualsiasi altra cosa, è possibile farlo. Il significato e l'implementazione di tali scopi spetta a te. Alcuni potrebbero essere molto generali, come READ e WRITE, ma forse PERCOLATE ha un significato molto specifico per il tuo Resource Server.