type - oauth2 oauth authorize




Qual è lo scopo del tipo di autorizzazione di concessione implicita in OAuth 2? (6)

Non so se ho una specie di punto cieco o cosa, ma ho letto le specifiche di OAuth 2 molte volte e ho esaminato gli archivi della mailing list, e devo ancora trovare una buona spiegazione del perché la Sovvenzione implicita flusso per ottenere i token di accesso è stato sviluppato. Rispetto alla concessione del codice di autorizzazione, sembra rinunciare all'autenticazione del client senza un motivo molto convincente. In che modo questo "è ottimizzato per i client implementati in un browser che utilizza un linguaggio di scripting" (per citare le specifiche)?

Entrambi i flussi iniziano allo stesso modo (fonte: http://tools.ietf.org/html/draft-ietf-oauth-v2-22 ):

  1. Il client avvia il flusso indirizzando lo user-agent del proprietario della risorsa sull'endpoint di autorizzazione.
  2. Il server di autorizzazione autentica il proprietario della risorsa (tramite l'utente-agente) e stabilisce se il proprietario della risorsa concede o nega la richiesta di accesso del client.
  3. Supponendo che il proprietario della risorsa conceda l'accesso, il server di autorizzazione reindirizza l'utente-agente al client utilizzando l'URI di reindirizzamento fornito in precedenza (nella richiesta o durante la registrazione del client).
    • L'URI di reindirizzamento include un codice di autorizzazione (flusso del codice di autorizzazione)
    • L'URI di reindirizzamento include il token di accesso nel frammento URI (Flusso implicito)

Ecco dove si dividono i flussi. In entrambi i casi l'URI di reindirizzamento a questo punto è relativo ad un endpoint ospitato dal client:

  • Nel flusso del codice di autorizzazione, quando l'agente utente raggiunge quell'endpoint con il codice di autorizzazione nell'URI, il codice su quell'endpoint scambia il codice di autorizzazione con le sue credenziali client per un token di accesso che può quindi utilizzare secondo necessità. Potrebbe, ad esempio, scriverlo in una pagina Web a cui potrebbe accedere uno script nella pagina.
  • Il flusso implicito ignora completamente questo passaggio di autenticazione del client e carica solo una pagina Web con script client. C'è un trucco carino qui con il frammento di URL che impedisce al token di accesso di essere passato troppo spesso, ma il risultato finale è essenzialmente lo stesso: il sito ospitato dal client serve una pagina con qualche script in esso che può afferrare il token di accesso .

Da qui la mia domanda: cosa è stato ottenuto qui saltando la fase di autenticazione del client?


Ecco i miei pensieri: Lo scopo del codice di autenticazione + token nel flusso del codice di autorizzazione è che il token e il segreto del client non saranno mai esposti al proprietario della risorsa perché viaggiano da server a server. Dall'altro lato, il flusso di concessione implicito è per i client che sono stati implementati interamente utilizzando javascript e in esecuzione nel browser del proprietario della risorsa. Non è necessario alcun codice lato server per utilizzare questo flusso. Quindi, se tutto accade nel browser del proprietario della risorsa, non ha più senso rilasciare il codice di autenticazione e il client segreto, perché il token e il segreto del client saranno comunque condivisi con il proprietario della risorsa. Includere il codice di autenticazione e il segreto del client rende il flusso più complesso senza aggiungere ulteriore sicurezza reale.

Quindi la risposta su "cosa è stato guadagnato?" è "semplicità".


La solita spiegazione è che la concessione implicita è più facile da implementare quando si utilizza un client JavaScript. Ma penso che questo sia il modo sbagliato di guardarlo. Se stai utilizzando un client JavaScript che richiede risorse protette direttamente tramite XMLHttpRequest, la concessione implicita è l'unica opzione, sebbene sia meno sicura.

La concessione del codice di autorizzazione fornisce ulteriore sicurezza, ma funziona solo quando si dispone di un server Web che richiede le risorse protette. Poiché il server Web può memorizzare il token di accesso, si corre meno rischi che il token di accesso venga esposto a Internet e si può emettere un token che dura a lungo. E poiché il server web è affidabile, può ricevere un "token di aggiornamento", in modo che possa ottenere un nuovo token di accesso quando scade quello vecchio.

Ma - e questo è un punto che è facile non notare - la sicurezza del flusso del codice di autorizzazione funziona solo se il server Web è protetto da una sessione, stabilita con l'autenticazione dell'utente (accesso). Senza una sessione, un utente non fidato potrebbe semplicemente effettuare richieste al server web, utilizzando l'id client, e sarebbe lo stesso come se l'utente avesse il token di accesso. L'aggiunta di una sessione significa che solo un utente autenticato può accedere alle risorse protette. Il client_id è solo l '"identità" della webapp JS, non l'autenticazione di detta webapp.

Significa anche che puoi terminare la sessione prima che il token OAuth scada. Non esiste un modo standard per invalidare un token di accesso. Ma se la tua sessione scade, il token di accesso è inutile, dal momento che nessuno lo sa, ma il server web. Se un utente non fidato ha ottenuto l'accesso alla chiave di sessione, sarà in grado di accedere alle risorse protette solo fino a quando la sessione è valida.

Se non c'è un server web, è necessario utilizzare la concessione implicita. Ma questo significa che il token di accesso è esposto a Internet. Se un utente non fidato vi accede, possono usarlo fino alla scadenza. Ciò significa che avranno accesso ad esso più a lungo che con una sovvenzione di codice di autorizzazione. Pertanto, potrebbe essere necessario prendere in considerazione l'eventualità di far scadere il token e evitare l'accesso a risorse più sensibili.


Non sono sicuro di aver capito correttamente la risposta e il commento di Dan. Mi sembra che la risposta abbia dichiarato alcuni fatti corretti, ma indica esattamente che cosa ha chiesto OP. Se capisco correttamente, il vantaggio principale del flusso di concessione implicito è che un client come l'app JS (ad esempio l'estensione di Chrome) non deve esporre il segreto del client.

Dan Taflin ha detto:

... nel flusso del codice di autorizzazione il proprietario della risorsa non ha mai bisogno di vedere il token di accesso, mentre nei client javascript è inevitabile. Il segreto del client potrebbe ancora essere mantenuto dai client javascript utilizzando il flusso del codice di autorizzazione, tuttavia ..

Forse ti ho frainteso, ma il client (app JS in questo caso) deve passare le credenziali del client (chiave e segreto del client) al server delle risorse nel flusso del codice di autorizzazione, giusto? Il segreto del cliente non può essere "tenuto da JS".


Penso che Will Cain abbia risposto a questa domanda dicendo "Non c'è alcun vantaggio per le credenziali del cliente per lo stesso motivo. (Qualsiasi client può tentare di utilizzare questo flusso.)" Inoltre considera redirect_uri per il flusso implicito forse "localhost" - nessuna richiamata viene creato dal server di autorizzazione per il flusso implicito. Poiché non c'è modo di pre-fidarsi del client, l'utente dovrebbe approvare il rilascio delle attestazioni dell'utente.


oltre alle altre risposte è anche importante rendersi conto che il profilo implicito consente un flusso del solo canale anteriore rispetto al flusso del codice di autorizzazione che richiede una richiamata al server di autorizzazione; questo diventa evidente in OpenID Connect, che è un protocollo SSO costruito su Auth 2.0 dove il flusso implicito è simile al binding SAML POST piuttosto popolare e il flusso del codice di autorizzazione è simile al binding dell'artifact SAML meno diffuso


https://tools.ietf.org/html/rfc6749#page-8

Implicito

La concessione implicita è un flusso di codice di autorizzazione semplificato ottimizzato per i client implementati in un browser che utilizza un linguaggio di scripting come JavaScript. Nel flusso implicito, invece di emettere un codice di autorizzazione al client, il client riceve direttamente un token di accesso (come risultato dell'autorizzazione del proprietario della risorsa). Il tipo di concessione è implicito, poiché non vengono emesse credenziali intermedie (come un codice di autorizzazione) (e successivamente utilizzate per ottenere un token di accesso).

Quando si emette un token di accesso durante il flusso di finanziamento implicito, il
il server di autorizzazione non autentica il client. In qualche
casi, l'identità del cliente può essere verificata tramite l'URI di reindirizzamento
utilizzato per consegnare il token di accesso al client. Il token di accesso può essere esposto al proprietario della risorsa o ad altre applicazioni con accesso allo user-agent del proprietario della risorsa.

Le sovvenzioni implicite migliorano la reattività e l'efficienza di alcuni
client (come un client implementato come applicazione nel browser),
poiché riduce il numero di round trip necessari per ottenere un
token di accesso.