Configurazione consigliata per entrambi i client Web e RIP mobile mobile sicurezza

Question

Mi rendo conto che ci sono un sacco di domande su questo argomento, e ho fatto ricerche per un paio di giorni. Voglio assicurarmi che la mia domanda sia il più specifica possibile dal momento che non ho ancora compreso pienamente l'approccio migliore.

Attualmente ho un sito django sviluppato, con il client Web che comunica probabilmente circa il 95% tramite un django-pistone JSON REST api. L'altro 5% è una funzionalità di accesso rimanente che passa attraverso i moduli POST con protezione CSRF. Idealmente, mi piacerebbe spostare il resto anche nell'API REST.

Sono ora al punto in cui ho bisogno di trovare la soluzione migliore per proteggere sia il client Web sia il client mobile (l'app deve ancora essere sviluppata) in un modo riutilizzabile e felicemente coesistente. Ho letto molti post in definitiva raccomandando OAuth2 (e https) per il lato mobile, ma sono ancora confuso su come impostare la sicurezza del client web. Sto anche cercando di comprendere l'aspetto di OAuth2 e se posso usare la forma a 2 zampe. Così com'è, il client web è autenticato da Django. Tecnicamente la funzionalità di jsonp è ancora attiva nel pistone, quindi penso che chiunque potrebbe utilizzare l'API di un'app di terze parti purché la loro sessione Web disponga dei cookie di autenticazione?

Sintesi di utilizzo del mio api:

1. L'API è un'interfaccia completamente privato per l'applicazione server di
2. Sarebbe l'ideale se l'API non poteva essere ampiamente riutilizzati entro il 3 web parti client mashups.
3. I dati non sono sensibili. Il suo solo un sito di social-tipo con le informazioni più personali è la roba di profilo utente di base come e-mail, indirizzi, ecc

Riassunto delle mie domande:

1. OAuth2 è il miglior approccio raccomandato per garantire l'accesso alle app mobili? Ha qualcosa a che fare con l'aspetto del client web? E se OAuth2 è raccomandato, dovrebbe essere una chiave a livello di applicazione che viene versionata con le versioni dell'app?
2. Il client Web che utilizza CSRF viene passato su ajax e basta disabilitare jsonp per garantire sempre la stessa origine? In sostanza, sto trattando separatamente la sicurezza del client Web?
3. Come dovrei organizzare l'url/istanza/sottodominio dell'app o qualsiasi altra cosa consigliata per mantenere la sicurezza web vs mobile? Ho solo bisogno di prefissi URL separati, uno per cellulari che utilizza regole diverse?

Sto cercando raccomandazioni specifiche per pistoni django per risolvere questi problemi. Ho già diramato il mio progetto e ho iniziato a giocare con questa versione biforcuta del pistone: https://bitbucket.org/jespern/django-piston-oauth2

Un'idea che avevo era di creare una risorsa pistone che prima controlla se è la sua stessa origine e quindi applica solo l'auth del django, altrimenti applica oauth2, ma non sono sicuro che sia appropriato.

Aggiornamento 1/1/2012

Da informazioni che Spike fornito, ho iniziato a lavorare con pistone-OAuth2.Ho finito per creare un fork di che aggiungere alcune correzioni per nonrel Django (MongoDB) e ho biforcato someones esempio di utilizzare anche OAuth2 e pistoni:

https://bitbucket.org/justinfx/django-piston-oauth2-nonrel-example

Ora il suo solo una questione di me davvero aggancio questo in su al mio progetto e farlo funzionare. Ma questi test funzionano tutti alla grande.

Answer 1

Sono tutto per OAuth2, quindi risponderò in base a tale soluzione.

OAuth2 è l'approccio migliore per la protezione delle app mobili accesso? Ha qualcosa a che fare con l'aspetto del client web? E se OAuth2 è raccomandato, dovrebbe essere una chiave a livello di applicazione che sia versionata con le versioni dell'app?

Sì, OAuth2 è ampiamente considerato l'approccio consigliato al momento. È molto più semplice di OAuth1. In realtà raccomanderei di leggere the spec invece di post di blog sulle specifiche in quanto la specifica stessa è scritta in modo molto chiaro. Oltre alle specifiche, è utile esaminare implementazioni definite come Facebook's e Foursquare's poiché non seguono le specifiche in ogni modo, ma apportano alcune modifiche per essere più pratiche e facili da usare.

Per quanto riguarda la versione delle versioni, dal punto di vista REST dogmatico, questo è frowned upon. Tuttavia, da una prospettiva più pragmatica, questa è una pratica estremamente comune e rende la vita molto più semplice sia per gli sviluppatori API che per i client. Consiglierei di leggere il blog di Apigee, dato che contengono molti post su argomenti come versioning.

qualora l'impiego CSRF client Web che è passata sopra ajax, e solo jsonp disable per garantire la sua sempre stessa origine? Fondamentalmente, sono I trattare separatamente la sicurezza del client web?

Se si utilizza una soluzione oauth2 completa, è necessario abilitare le richieste API cross-site. Per negare le app non si sa, si può semplicemente aggiungere i controlli per che quando si guardano le access_tokens essere passati in Ecco qualche lettura circa le diverse opzioni che si hanno:.

http://blog.apigee.com/detail/crossing_the_streams_handling_cross-site_api_requests/

Come dovrei andare a organizzare l'url/istanze/sottodomini di app o qualsiasi cosa si consiglia di mantenere la sicurezza web vs mobile? I hanno solo bisogno di prefissi URL separati, uno per cellulari che utilizza diverse regole ?

Basta decidere cosa funziona per voi. Un sacco di persone hanno il loro sito mobile su "m.mysite.com" o "mobile.mysite.com" al giorno d'oggi. Questa decisione non è realmente correlata all'intera discussione sull'autenticazione se si utilizza un'implementazione OAuth2 completa.

Cerco django-pistone raccomandazioni specifiche per risolvere questi problemi.Ho già ramificata mio progetto e ha iniziato a giocare con questa versione forcella del pistone: https://bitbucket.org/jespern/django-piston-oauth2

Non ho familiarità con questo, come io uso tastypie. Se non funziona bene per voi, v'è un eccellente server autonomo Django OAuth2 che ho usato:

https://github.com/hiidef/oauth2app