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?
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
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. –