OAuth alternativa per un sistema di 2 parti

6

Sto scrivendo un servizio RESTful (Java EE, Jersey) e un'applicazione client che comunica con esso, e desidero assicurarlo e memorizzare qualsiasi nome utente & password dedicate nel mio database.

Non voglio che il client memorizzi localmente il nome utente e la password, non in alcuna forma come base-64 o altra codifica, preferisco avere qualcosa come il sistema di autorizzazione OAuth2, dove l'app client memorizza solo un aggiornamento & accedi ai token dopo che il proprietario della risorsa ha effettuato l'accesso, ma non è necessario fornire l'accesso ai servizi di terze parti.

La protezione del mio servizio utilizzando l'autenticazione di base significa che l'app client deve memorizzare la password e inviarla per ogni richiesta futura, quindi non è quello che mi serve.

Sono consapevole che OAuth è destinato a situazioni diverse, dove ci sono più di 2 parti coinvolte ( vedi altre domande ).

come menzionato qui link : OAuth is the only realistic choice for a web application that itself uses another web application's API on behalf of the user. For instance, consider a web application that integrates with Twitter. (Perhaps it's a geolocation app like Foursquare that offers the ability to tweet where you are and what you're doing.)

Quindi qual è il metodo standard corretto per proteggere il mio servizio RESTful se non desidero reinventare la ruota e creare il mio metodo auth, e se "Basic" non è ciò di cui ho bisogno perché mi costringe a memorizzare il credenziali localmente sul client e OAuth è probabilmente un eccesso con la sua natura di accesso di terze parti.

P.S- Desidero offrire agli utenti un'opzione per accedere al mio servizio tramite Facebook o open-id, ma questa è un'altra storia che immagino.

    
posta Alon Amir 10.10.2013 - 11:34
fonte

3 risposte

3

Puoi usare OAuth 2.0 molto bene. OAuth ti offre vari grant_types per supportare vari casi d'uso. Il caso d'uso che hai avrà grant_type = password, questo è un flusso a 2 zampe, a differenza del 3-Legged dove ci sono 3 parti coinvolte, cioè.

resource_owner (enduser)
Client (third party app)
Resource server (Server)

come server & la tua applicazione mobile appartiene allo stesso gruppo di fiducia, dovresti utilizzare 2 Legged OAuth (grant_type = password) il flusso generale è

POST /oauth/token
Authorization: Basic base64Encoded(<client_id>:<secret>)
username=a&password=b&grant_type=password

Questo ti restituirà con access_token e refresh_token.

    
risposta data 07.01.2014 - 13:45
fonte
2

Ho avuto un problema simile un paio di anni fa e ho trovato questo articolo estremamente utile.

link

L'idea di base è di avere il client e il server per avere un segreto condiviso. Quel segreto condiviso non viene mai comunicato via cavo, ma viene utilizzato per creare un token (HMAC) che verifica la richiesta. Il client deve conoscere l'algoritmo per creare l'HMAC (può essere fornito tramite una libreria client) e un segreto (simile a una password, ma non una password).

Nella tua domanda hai detto che non vuoi che il tuo cliente debba memorizzare la password. Questa soluzione richiede che il client cerchi il segreto, quindi potrebbe non soddisfare le tue esigenze; tuttavia, non richiede che il client esegua l'autenticazione o l'accesso al servizio.

(Nota a margine, hai menzionato la memorizzazione delle password come base64.Non memorizzare mai le password come base 64. La codifica non è la stessa cosa della crittografia.)

    
risposta data 14.10.2013 - 21:22
fonte
2

Oauth (non è sicuro di Oauth2) offre l'accesso di terze parti alle risorse utilizzando la combinazione di chiave utente e token di accesso. Pertanto, per le comunicazioni di 2 parti, è possibile eseguirne il piegamento per utilizzare solo la chiave utente senza token di accesso (o vuoto). Questo ti darà solo un modo per autenticare le richieste usando l'intestazione di autorizzazione di Oauth.

Quindi, ciò che usi come chiave utente dipende da te. Potrebbe essere semplice come utilizzare l'id utente come chiave utente e la password utente come segreto utente, quindi non dovrai memorizzarli ovunque.

    
risposta data 13.11.2013 - 23:22
fonte

Leggi altre domande sui tag