L'ultima volta che ho implementato la sicurezza, ho usato Apache Shiro . Forniva un metodo affidabile e sicuro per implementare un accesso client / server sicuro ai dati dell'utente. Non solo ha fornito algoritmi di hashing e crittografia per garantire che le password di testo non fossero disponibili, ma forniva anche una struttura in cui utilizzare il sistema di sicurezza. Ogni componente può verificare il livello di autenticazione dell'utente corrente e quindi consentire / disabilitare i vari componenti da consegnare all'utente.
Mi sono integrato con un'applicazione GWT che consentiva account utente locali, account Facebook, twitter, linkedin, plaxo e google +. Ha gestito tutti i casi senza problemi.
Quando Shiro si integra con l'applicazione Web, utilizza la sessione lato server per memorizzare un identificatore per l'utente corrente. Questo viene assegnato solo nella variabile lato server quando un client fornisce correttamente un'autenticazione valida. Implementano anche un timeout configurabile per limitare il tempo di autenticazione.
Una cosa che non possono proteggere è un uomo nel mezzo dell'attacco, ma non è la tua posizione da proteggere contro quel tipo di attacco. Forza l'uso di SSL e ti sei coperto il culo.
Dai un'occhiata a questo elenco dei 10 principali rischi per la sicurezza come fonte di ispirazione.
Per quanto riguarda il modo in cui ciò si applica alla tua applicazione client, sarai intrinsecamente insicuro. In genere, si inserisce un codice univoco all'interno dell'applicazione per consentire solo a tale applicazione di comunicare con il proprio servizio Web. Una volta che una persona scarica il client, quel codice è facilmente disponibile. Qualsiasi sniffer di pacchetti sarà in grado di vedere le comunicazioni. Usa SSL, ed è più difficile, ma un decompilatore fornirà il testo.
Se limiti l'accesso agli utenti che effettuano l'autenticazione tramite il tuo servizio web, allora sei un buon passo avanti.