5

Durante l'utilizzo dell'API di Twitter, mi sono imbattuto nello oauth_signature che è fondamentalmente un hash del (corpo della richiesta + parametri di richiesta + nonces/timestamp + un consumer_secret). consumer_secret è noto solo all'applicazione che sta inviando la richiesta.Non è oauth_signature reinventare la ruota SSL?

Nel caso di Twitter:

  • tutta la comunicazione deve avvenire su SSL.
  • twitter invia il consumer_secret a ciascuna applicazione autorizzata.

Poiché l'uso primario del oauth_signature è impedire MITMs (cioè senza seni (manomissione in transito) :), mi sembra che questo particolare caso d'uso potrebbe essere risolto tramite SSL reciproco

  • Twitter, invece di emettere il consumer_secret, può emettere certificati SSL per ogni applicazione.

Mentre questa idea di certificati ssl client potrebbe sembrare come gli internet arcani degli anni '90, non ha avuto successo in gran parte a causa della difficoltà nella verifica della catena di attendibilità per i certificati client. Questo problema non si pone qui perché Twitter sarebbe l'unico emittente E verificatore dei certificati. Lo svantaggio sarebbe uno sforzo molto più impegnativo per conto di Twitter per produrre i certificati ssl dell'applicazione/client iniziali, ma il payoff sarebbe nella semplicità dell'API REST, che può basarsi sulla garanzia che il client è chi dice di essere.

Si noti che Twitter è solo un esempio in questo caso. AFAIK, la maggior parte degli altri implementatori di oauth utilizzano una strategia simile ei punti qui si applicano a qualsiasi implementatore OAuth su vasta scala che già impone SSL.

Cosa mi manca qui? Internet Inertia?

risposta

-1

I certificati SSL reciproci, pur essendo una buona idea, non risolvono esattamente il problema che OAuth sta cercando di risolvere. OAuth ha due set di token. Uno per l'applicazione (che potrebbe essere sostituita dai certificati SSL), ma anche per l'utente specifico. I certificati SSL non aiutano quando si tenta di determinare se questa applicazione autorizzata è autorizzata ad accedere a questo specifico utente.

+0

Ti stai perdendo la domanda. Non sto dicendo che i certificati reciproci SSL risolveranno il problema risolto da OAuth. Sto dicendo che il meccanismo 'oauth_signature' sta sostanzialmente reinventando l'autenticazione a due vie che i certificati mutui-SSL già forniscono. – Manav

+1

Ma i certificati SSL reciproci risolvono solo metà del problema (il lato del token dell'applicazione) e non fanno nulla per il lato del token del consumatore. E se guardi OAuth 2.0, si sono mossi in quella direzione. –