In che modo sostituire i token Bearer con HMAC funziona in OAuth 2.0 e in che modo validare il client / server?

6

Questa classe di Pluralsight tratta i token Bearer , e che una delle cose che mancano a OAuth 2.0 è la convalida basata su HMAC. Altrove nei blog di thinktecture, sono chiamati token PoP (Prova di possesso)

La convalida basata su HMAC impedirebbe gli attacchi basati su CSRF in cui lo scambio del token al portatore comporterebbe una rappresentazione.

Ciò che mi ha confuso è che in una delle diapositive sui rischi di OAuth 2.0, Dominic Baier ha discusso che questa convalida si sarebbe verificata sul client.

La convalida basata su HMAC non è mai stata aggiunta alle specifiche OAuth e la sua omissione è stata una delle ragioni principali per cui Eran Hammer (autore originale di OAuth) ha deciso di rimuovere il suo nome dalle specifiche.

Immergendomi in questo più profondo, sono un po 'confuso su come i token HMAC in OAuth sarebbero:

  1. Costruito in code o implicit flussi
  2. In che modo il client convaliderà questi token HMAC? Devo presumere che si tratta solo di applicazioni SPA?
  3. La struttura JWT in OpenID Connect risolve tutti i problemi HMAC in OAuth 2.0?
posta random65537 10.08.2016 - 05:47
fonte

2 risposte

3

Qualunque sia il flusso, il token MAC verrà generato allo stesso modo: una chiave segreta simmetrica e un ID vengono inviati al client una volta . Questo segreto non viene mai inviato di nuovo sul filo.

Il client non convalida il token * , il client lo usa come userebbe un token al portatore, tranne per il fatto che il segreto non viene inviato via cavo e quindi non può essere trapelato:

  +--------------+                                        +--------------+
  |              |>------Request with authenticator------>|              |
  |              |                                        |   Resource   |
  |    Client    |                                        |    server    |
  |              |<--------Requested resource------------<|              |
  |              |                                        +--------------+
  +--------------+                                                ^
         ^                                                        |
         |                                                        |
         |                                                        |
         |                                                        |
         |                                                 MAC algorithm  
   MAC algorithm                                           over key+params
   over key+params

Il client costruisce l'autenticatore che calcola un MAC utilizzando la chiave segreta e alcuni parametri (che include l'ID del token, un nonce, un timestamp e altri dati) e lo allega alla richiesta.

Il server delle risorse (o un terzo server utilizzato da RS per convalidare i token) conosce questa chiave segreta, quindi esegue gli stessi calcoli eseguiti dal client utilizzando gli stessi parametri. Se tutto corrisponde, procede con la richiesta.

Il server ha anche il compito di impedire attacchi di riproduzione controllando il timestamp e impedendo il riutilizzo nonce.

Questo protegge di nuovo molti scenari in cui il token potrebbe essere trapelato: errata configurazione di TLS / bug, endpoint controllati dagli hacker che trovano la loro strada nel database del cliente, ecc.

Riguardo alla tua terza domanda, sì e no. La bozza delle specifiche MAC OAuth2 definisce alcune affermazioni per JWT per codificare informazioni necessarie per l'emissione e l'uso di token MAC tramite JWT, ma OpenID Connect utilizza ancora token al portatore.

Il principale problema con i token bearer è che lo sviluppatore del client deve essere molto attento alla sicurezza e che la sua sicurezza dipende esclusivamente da TLS.

Molte persone fraintendono quest'ultima affermazione e concludono che OAuth2 è intrinsecamente insicuro, inutile e condannato. Ancora peggio, ripetono ciecamente questo tipo di conclusioni in discussioni, post e commenti e semplicemente confondono le persone.

OAuth2 è ottimo per alcuni casi d'uso e fa schifo per gli altri. Richiede una buona comprensione di alcuni principi di sicurezza. Richiede anche dei compromessi. Ma è là fuori, funziona e risolve un problema molto difficile.

L'uso dei MAC non è mai stato standard, ma la bozza è abbastanza buona e facilmente implementabile. Oggi ci sono anche diverse alternative.

(*) : intendo che il client non esegue la convalida del MAC. Ovviamente, il pubblico e altri campi devono ancora essere convalidati.

    
risposta data 12.09.2016 - 19:43
fonte
0

OAuth WG sta sviluppando un'estensione di sicurezza che consente ai token di accesso di associare un certificato X.509 del client. È relativamente semplice da implementare con client e server di risorse e funziona anche con client pubblici: link

    
risposta data 18.08.2017 - 12:04
fonte

Leggi altre domande sui tag