Perché OpenID Connect usa il token id come parametro di querystring al logout?

Naviga le tue risposte
4

OpenID Connect, nel flusso implicito, restituisce il token id come #fragment sull'URI di ritorno in modo specifico in modo che il token ID non venga registrato nei log del server web.

Tuttavia, il logout di OpenID Connect specifica un parametro querystring id_token_hint che sarebbe il token id dell'utente che viene disconnesso.

link

RP-Initiated Logout

An RP can notify the OP that the End-User has logged out of the site, and might want to log out of the OP as well. In this case, the RP, after having logged the End-User out of the RP, redirects the End-User's User Agent to the OP's logout endpoint URL. This URL is normally obtained via the end_session_endpoint element of the OP's Discovery response, or may be learned via other mechanisms.

This specification also defines the following parameters that are passed as query parameters in the logout request:

id_token_hint

RECOMMENDED. Previously issued ID Token passed to the logout endpoint as a hint about the End-User's current authenticated session with the Client. This is used as an indication of the identity of the End-User that the RP is requesting be logged out by the OP. The OP need not be listed as an audience of the ID Token when it is used as an id_token_hint value.

post_logout_redirect_uri

OPTIONAL. URL to which the RP is requesting that the End-User's User Agent be redirected after a logout has been performed. The value MUST have been previously registered with the OP, either using the post_logout_redirect_uris Registration parameter or via another mechanism. If supplied, the OP SHOULD honor this request following the logout.

state

OPTIONAL. Opaque value used by the RP to maintain state between the logout request and the callback to the endpoint specified by the post_logout_redirect_uri query parameter. If included in the logout request, the OP passes this value back to the RP using the state query parameter when redirecting the User Agent back to the RP.

At the logout endpoint, the OP SHOULD ask the End-User whether he wants to log out of the OP as well. If the End-User says "yes", then the OP MUST log out the End-User.

Da una parte riesco a capire perché sia desiderabile consentire solo a un utente autenticato di autenticarsi, per prevenire certi attacchi denial of service. D'altra parte, tuttavia, questo processo lascerà id_tokens sparsi attraverso i log di qualsiasi server che registra i parametri di querystring.

Qualcuno può far luce sul perché questa sia considerata una buona idea?

Grazie

    
posta Alex White 23.11.2016 - 12:02
fonte

1 risposta

1

La codifica dei frammenti aiuta effettivamente gli scenari dei registri del server Web, ma non direi che è stata specificatamente utilizzata a causa di ciò.

Tuttavia, poni un'interessante domanda sull'inclusione delle credenziali del token ID in una richiesta GET . Penso che alcune cose possano permettere che questo sia accettabile:

  • Se il client utilizza il flusso implicito, la specifica impone anche l'uso di un nonce e inoltre indica che dovrebbe essere utilizzato per impedire attacchi di riproduzione. Se questo è il caso, la perdita del token dopo che è già stata utilizzata non dovrebbe portare a un problema significativo in quanto quel token non sarebbe più accettato dal client al fine di avviare una nuova sessione.

    The value of the nonce Claim MUST be checked to verify that it is the same value as the one that was sent in the Authentication Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is Client specific.

  • È molto probabile che il token stesso possa già essere scaduto quando si verifica effettivamente il logout, quindi non sarebbe possibile riutilizzarlo sul client. (il server di autorizzazione lo utilizza solo per il contesto, quindi non richiede rigorosamente un token valido)

Nel complesso, penso che disporrete di implementazioni sicure per le quali il passaggio del token in quella richiesta non causerà ulteriori danni e quindi avrà altre implementazioni in cui potrebbe rivelarsi una minaccia significativa.

Tuttavia, questa caratteristica non si applica solo a quella specifica parte della specifica, è una cosa generale ... l'autenticazione e l'autorizzazione sono argomenti complessi in cui i piccoli dettagli hanno un grande impatto e dove il panorama cambia continuamente. Ecco perché è così pericoloso girare i tuoi sistemi di autenticazione.

    
risposta data 23.11.2016 - 15:19
fonte

Leggi altre domande sui tag

Qual è il modo più consigliato per esporre un file a un computer in una rete esterna in modo sicuro? Il cloud storage è sicuro da usare se utilizzo gpg e il mio metodo è sicuro?