L'implementazione di un 2 Legged OAuth Provider

Question

Sto cercando di trovare la mia strada intorno al spec OAuth, le sue esigenze e le eventuali implementazioni posso trovare e, finora, sembra davvero come più problemi che ne vale la pena, perché sto avendo problemi a trovare una singola risorsa che tira tutto insieme. O forse è solo che sto cercando qualcosa di più specializzato della maggior parte dei tutorial.

Ho una serie di API esistenti - alcuni in Java, alcuni in PHP - che ora bisogno di assicurare e, per una serie di ragioni, OAuth sembra la strada giusta da percorrere. Purtroppo, la mia incapacità di rintracciare le giuste risorse per aiutarmi a ottenere un fornitore attivo e funzionante ha impugnato tale teoria. Dal momento che la maggior parte di questo sarà il sistema a sistema l'utilizzo di API, avrò bisogno di implementare un provider di 2 zampe. Con questo in mente ...

1. Qualcuno sa di eventuali buoni tutorial per l'attuazione di un fornitore di OAuth 2 zampe con PHP?
2. Dato che ho API a protezione diretta in 2 lingue, ho bisogno di implementare un fornitore sia o c'è un modo per creare il provider come "front controller" che posso incanalare tutte le richieste attraverso?
3. Quando sicuri i servizi di PHP, per esempio, devo garantire ogni API individualmente includendo le risorse necessarie su ogni fornitore?

Grazie per il vostro aiuto.

Answer 1

Vorrei fare un passo indietro e pensare a quello che un cliente correttamente autenticato sta per essere l'invio di voi.

Si può memorizzare le chiavi e le credenziali in un database comune accessibile da entrambe le serie di servizi, e solo implementare il provider OAuth in una lingua? Quando l'utente invia una richiesta a un servizio (PHP o Java) si quindi controllare contro il negozio comune. Quando l'utente è la creazione del client OAuth poi si fa tutto questo attraverso sia un PHP o Java app (la vostra preferenza), e memorizzare le credenziali nel DB comune.

Ci sono alcuni fornitori di OAuth scritti in altre lingue che si potrebbe desiderare di dare un'occhiata a:

• PHP - http://term.ie/oauth/example/ (vedere in fondo alla pagina)
• Rubino - http://github.com/mojodna/sample-oauth-provider
• http: //blog.bittercoder .com / PermaLink, guid, 0d080a15-b412-48cf-b0d4-e842b25e3813.aspx

Answer 2

Rob, non sicuro dove è atterrato su questo, ma vuole aggiungere i miei 2 centesimi nel caso in cui nessun altro imbattuto in questa domanda.

I più o meno avuto la stessa domanda un paio di mesi fa e sentir parlare di "OAuth" per la parte migliore di un anno. Stavo sviluppando un'API REST avevo bisogno di garantire così ho iniziato a leggere su OAuth ... e poi i miei occhi hanno cominciato a rotolare indietro nella mia testa.

Probabilmente ho dato una buona giornata solido o 2 di skimming e la lettura fino a quando ho deciso, proprio come te, che OAuth era confusa spazzatura e appena rinunciato su di esso.

Allora ho iniziato la ricerca modi per proteggere le API in generale e ha iniziato a ottenere una migliore comprensione su modi per farlo. Il modo più popolare sembrava essere l'invio di richieste all'API insieme a una somma di controllo di l'intero messaggio (codificato con un segreto che solo tu e il server sa) che il server può utilizzare per decidere se il messaggio era stato manomesso su di esso la strada dal cliente, in questo modo:

1. Il client invia /user.json/123?showFriends=true&showStats=true&checksum=kjDSiuas98SD987ad
2. Server ottiene tutto ciò che, guarda in alto utente "123" nel database, carica la sua chiave segreta e quindi (usando lo stesso metodo del client utilizzato) ricalcola è checksum PROPRIO dato gli argomenti richiesta.
3. Se checksum generato del server e del client inviato checksum match up, la richiesta è OK ed eseguito, in caso contrario, è considerato manomesso e respinto.

Il checksum è chiamato HMAC e se volete un buon esempio di questo, è ciò che Amazon Web Services utilizza (che chiamano l'argomento 'firma' non 'checksum' però).

Quindi, dato che uno dei componenti chiave di questo lavoro è che il client e il server devono generare il HMAC nello stesso modo (altrimenti non corrisponderanno), ci devono essere regole su come combinare tutte le argomenti ... poi improvvisamente ho capito tutto quello che "naturale byte-ordinamento dei parametri" merda da OAuth ... era solo definire le regole per come generare la firma perché doveva.

Un altro punto è che ogni param di includere nella generazione HMAC è un valore che quindi non può essere manomesso quando si invia la richiesta.

Quindi, se solo codificare lo stelo URI come la firma, ad esempio:

• /user.json == askJdla9 / kjdas + Askj2l8add

quindi l'unica cosa nel messaggio che non può essere manomesso è l'URI, tutti gli argomenti può essere manomesso, perché non fanno parte del "checksum" valore che il server ricalcolare.

In alternativa, anche se si include OGNI param nel calcolo, è ancora corre il rischio di "attacchi replay", in cui un uomo di mezza dannoso o evesdropped può intercettare una chiamata API e continuare inviare nuovamente al server più e più volte.

Si può rimediare con l'aggiunta di un timestamp (utilizzare sempre UTC) nel calcolo HMAC pure.

PROMEMORIA: Dal momento che il server deve calcolare la stessa HMAC, è necessario inviare insieme qualsiasi valore si utilizza nel calcolo TRANNE LA CHIAVE SEGRETA (OAuth chiama un consumer_secret credo). Quindi, se si aggiunge timestamp, assicurarsi che si invia un parametro timestamp con la vostra richiesta.

Se si vuole fare l'API sicuro dagli attacchi di replay, è possibile utilizzare un valore nonce (si tratta di un valore d'uso 1-tempo il server genera, dà al cliente, il client utilizza nel HMAC, rimanda la richiesta , il server di conferma e poi segna il valore nonce come "usato" nel DB e non lascia mai un'altra richiesta di usarlo di nuovo).

Nota: 'nonce' sono un modo veramente esatto per risolvere il problema "attacco replay" - timestamp sono grandi, ma perché i computer non sempre hanno valori timestamp in-sync, è necessario consentire una finestra accettabile sulla lato server di come "vecchio" di una richiesta potrebbe essere (diciamo 10 minuti, 30 minuti, 1 ora .... Amazon utilizza 15 minuti) prima di accettare o rifiutare. In questo scenario l'API è tecnicamente vulnerabili durante l'intera finestra di tempo.

Ipensano valori nonce sono grandi, ma dovrebbe solo bisogno di essere utilizzato in API che sono fondamentali mantengono la loro integrità. Nel mio API, non ho bisogno, ma sarebbe banale per aggiungere in seguito, se gli utenti lo richiedeva ... Vorrei letteralmente solo bisogno di aggiungere una tabella "nonce" nel mio DB, esporre una nuova API per clienti come:

• /nonce.json

e poi quando inviano che torna a me nel calcolo HMAC, avrei bisogno di controllare la DB per assicurarsi che non era mai stato usato prima e, una volta utilizzato, contrassegnare come tale nel DB, quindi se una richiesta è venuto MAI di nuovo con lo stesso nonce avrei respingerla.

Riepilogo

In ogni caso, per fare una lunga storia breve, tutto quello che ho appena descritto è in fondo ciò che è noto come "2 zampe OAuth". Non c'è quel passo aggiunto di fluire all'autorità (Twitter, Facebook, Google, a prescindere) di autorizzare il cliente, questo passo viene rimosso e invece il server si fida implicitamente al cliente se il che stanno inviando match up HMAC. Ciò significa che il cliente ha la SECRET_KEY destra ed è la firma è messaggi con esso, in modo che il server di fida di esso.

Se si inizia a guardare intorno in linea, questo sembra essere il metodo preferito per il fissaggio metodi API ora a adays, o qualcosa di simile. Amazon utilizza quasi esattamente questo metodo a meno che usino un metodo di combinazione leggermente diverso per i loro parametri prima di firmare il tutto per generare il HMAC.

Se siete interessati ho scritto questa intero viaggio e il pensiero-processo come stavo imparando esso. Questo potrebbe aiutare a fornire un tour guidato pensando di questo processo.