OAuth è sempre la scelta giusta (e quando non lo è)

Question

OAuth è sempre la scelta giusta (e quando non lo è)

#1 da (1 voti)

7

Sto creando un'applicazione mobile che deve interagire su una base per utente con un'API. Avendo lavorato su diversi progetti come client di API di terze parti, il mio primo pensiero era di andare con OAuth. Tuttavia, ci ho pensato e non ho intenzione di aprire l'API pubblicamente ad altri consumatori - l'unico consumatore sarà sempre la mia app mobile, quindi pensavo se OAuth fosse effettivamente la soluzione migliore? O è eccessivo?

Poi ho letto questo articolo fornendo consulenza su un processo di Google, che suggerisce il seguente approccio per esattamente questo scenario :

Incorpora una visualizzazione Web nella tua app con un normale modulo di accesso basato sul Web
in caso di accesso riuscito, passa cookie sicuro all'app mobile che dispone di token protetto
utilizza il token nelle future richieste API

(assumendo tutto su https ecc.)

Questo sembra molto più semplice di qualsiasi implementazione OAuth, e potrebbe essere fatto facilmente utilizzando la catena di filtri / autenticazione Spring Security (il mio codice lato server è Java e Spring MVC / Secutiry ecc.). Sembra interessante l'approccio consigliato di Google, che a mio avviso ha aggiunto una certa credibilità alla soluzione.

Supponendo che con la soluzione di cui sopra includessi anche una chiave per app mobile ecc. (solo per impedire a qualsiasi cellulare di colpire il modulo / API), sembra che avrebbe lo stesso problema di OAuth in quanto devo includere la mia app chiave incorporata nel codice mobile (che potrebbe essere decompilata ecc.)

Ho letto anche questo articolo sull'approccio Amazon ( apparentemente simile a un'implementazione OAuth 1), che sembra possa essere un'estensione ragionevole della soluzione proposta da Google sopra e piuttosto che inviare il token al server, usarlo come chiave per cancellare i dati della richiesta.

Sono abbastanza nuovo nell'implementare qualsiasi cosa in sicurezza al di là della normale sicurezza utente / password basata sul web - apprezzeremmo su quando utilizzare OAuth per le app mobili e se le due soluzioni precedenti (amazon e amp; google) sono adatte allo scopo di se sono stati sostituiti da OAuth 2.

authentication oauth mobile

posta rhinds 04.03.2014 - 17:07

fonte

1 risposta

Leggi altre domande sui tag authentication oauth mobile

Sblocca codici per un'app mobile Due prende la crittografia PHP bidirezionale - quale è preferibile?

score 1 · Accepted Answer

La risposta alla prima parte della domanda è semplice: nessun protocollo è sempre la scelta giusta.

OAuth risolve (beh, offre una soluzione a) un sacco di piccoli fastidiosi problemi come l'autorizzazione dei client e la protezione delle risorse in modo semi-granulare attraverso browser, client attivi e qualsiasi cosa ci sia nel mezzo.

Può essere eccessivo, che è una buona ragione per non usarlo. Non esegue l'autenticazione (OpenID Connect è l'estensione authn di OAuth) e non offre certi comportamenti che altri protocolli fanno, ad es. SAML, ma d'altra parte potrebbe essere una buona cosa.

La soluzione offerta da Google ha molte caratteristiche di OAuth, ma fa molto affidamento sul cookie, e non sembra che possa essere scalabile per l'uso pubblico. Se non ti interessa esporre pubblicamente le API, potrebbe andar bene, ma se vuoi farlo allora OAuth sarebbe un approccio migliore rispetto a quella soluzione.

Se si utilizza la rotta OAuth, è probabile che si desideri supportare l'ultima versione in quanto consente l'accesso a OpenID Connect. Altrimenti sei bloccato a costruire il tuo mezzo di autenticazione e tutti i client dovranno implementare il tuo design personalizzato.