Perché non riesco a utilizzare la modalità di risposta alla query con il tipo di risposta id_token (flusso "implicito")?

Question

Perché non riesco a utilizzare la modalità di risposta alla query con il tipo di risposta id_token (flusso "implicito")?

#1 da (1 voti)

9

Anche se penso che OpenID 2.0 sia un protocollo di autenticazione più pulito e migliore di OpenID Connect, devo implementare un IdP OpenID Connect.

Un punto che mi piace in OpenID 2.0 è che l'IdP può restituire un'identità firmata al Relying Party (tramite l'agente utente) e non c'è un ulteriore round trip tra RP e l'IdP.

A prima vista, OpenID Connect definisce un flusso "implicito" che a me sembra soddisfacente. Ma quando guardo i dettagli, sembra che sia progettato solo per essere usato con "Client implementati in un browser utilizzando un linguaggio di scripting".

Ho pensato che potrei comunque utilizzare il flusso "Implicito" con un RP lato server, utilizzando la modalità di risposta "query", ma " OAuth 2.0 Prove di codifica di tipo a risposta multipla "Il documento vieta esplicitamente l'uso della modalità di risposta" query "con il tipo di risposta id_token ...

Perché è proibito? E più in generale, perché il flusso "Implicito" è corrugato?

A quanto ho capito, finché i token ID sono firmati e l'RP usa (e verifica) nonces, il flusso "Implicit" dovrebbe essere sicuro.

openid-connect

posta user2233709 15.03.2017 - 14:17

fonte

1 risposta

Leggi altre domande sui tag openid-connect

Autenticazione API mobile Come gestire un honeypot nel cloud?

score 1 · Answer 1

And more generally, why is the “Implicit“ flow frowned at?

Perché il token di accesso è esposto all'agente utente (browser). Vedi Diagramma di flusso implicito nelle specifiche OAuth 2 , quindi contattaci al flusso del codice di autorizzazione che non espone il token al programma utente.

... explicitly forbids the use of “query” Response Mode with the id_token response type... Why is it forbidden ?

Definizione rapida:

scheme://host:port/path?query#fragment

La porzione "query" di un URL è facilmente ispezionabile da molte parti - può essere registrata dall'agente utente (ad esempio la cronologia del browser) e viene spesso trovata nei registri delle richieste del server Web. La regola empirica è di non inviare mai alcuna informazione sensibile (ad esempio token, codici di autorizzazione, password) tramite il parametro "query".

Tuttavia, la parte "frammento" non viene mai inviata nelle richieste HTTP, né verrà visualizzata nelle intestazioni Referer. Solo l'esecuzione di JavaScript sull'agente utente (browser) avrebbe accesso ad essa.

Ad esempio, un client (browser) potrebbe fare una richiesta come questa:

GET /authorize?
  response_type=id_token%20token
  &client_id=s6BhdRkqt3
  &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
  &state=af0ifjsldkj HTTP/1.1
Host: server.example.com

Il server di autenticazione risponde con (nota il "frammento" denotato da "#"):

HTTP/1.1 302 Found
Location: https://client.example.org/cb#
  access_token=SlAV32hkKG
  &token_type=bearer
  &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
  &expires_in=3600
  &state=af0ifjsldkj

Il browser esclude quindi il "frammento" quando reindirizza alla posizione di destinazione. Si prevede che il codice JavaScript nel browser invii i token pertinenti utilizzando un meccanismo più sicuro (ad esempio il corpo POST).

Ci sono quirks tra i vari browser, ma nulla di evidente che sconfigge l'assunto di sicurezza.