OAuth a due vie - ricerca di informazioni

Question

Desidero implementare un nuovo API basato su REST sulla nostra infrastruttura e OAuth sembra essere la strada da percorrere.

Per la nostra applicazione, non ci sarà prima essere solo server-to-server di accesso, che sarà completamente senza restrizione. Credo che questo sia chiamato l'autorizzazione a due gambe.

Più tardi, vorremmo consentire l'API per essere consumato dal browser, che si trasformerà la nostra autorizzazione in tre zampe.

C'è un buon punto di partenza per l'implementazione di questo? Come possiamo autorizzare completamente un server e in futuro aggiungere un'autorizzazione limitata per utente?

Le specifiche OAuth non sono molto utili in questi scenari, ma credo che questo implichi la necessità di creare una sessione senza scadenza per l'accesso da server a server e in seguito aggiungere sessioni normali con accesso limitato per l'utente. solo API.

Spero di trovare punti di partenza per ulteriori informazioni, fatemelo sapere!

OAuth è per me? Sto solo cercando un sistema di richiesta autenticato, e solo il consumatore e il fornitore di servizi esistono in questo scenario. L'utente finale non entra per giocare!

Answer 1

OAuth finirà per essere troppo difficile per le nostre esigenze. Ho deciso di adottare lo schema di autenticazione di Amazon S3, semplicemente perché si adatta meglio al nostro modello.

Grazie per aiutare trovare una risposta anche se ..

Answer 2

Ricordare di distinguere tra autenticazione e autorizzazione. In alcuni punti, credo che l'OP mescoli i due.

Per esempio, una volta al server autentica qualcuno, di solito esplicitamente o implicitamente (utilizzando i cookie) fornisce un token di autenticazione in modo che le successive richieste sono già autorizzati.

Spetta al server per quanto tempo durano le credenziali. È intelligente per il piano che le credenziali scadano a un certo punto. È sufficiente che il server client sia pronto per eseguire nuovamente l'autenticazione ogni volta che riceve la risposta di errore "autorizzazione scaduta".

Non si vuole per cercare di fornire una sessione di "non-scadenza", in quanto:

1. Tutto scade ad un certo punto. Ad esempio, in che modo il server client sarà in grado di avviare nuovamente l'accesso all'applicazione se perde potenza o viene riavviata?

2. Stai creando un sistema inflessibile. Tendono a rompere più spesso.

3. Dal momento che si sa che si desidera aggiungere altri tipi di account di accesso per il futuro, invece di due tipi di account di accesso (client server e client browser), fare un solo tipo di login ora. Il lavoro aggiuntivo per il server client sarà quello di implementare una funzionalità di "re-login come necessario".

Answer 3

Ya, OAuth è probabilmente per voi.

Ci sono in realtà due specifiche OAuth, la versione a 3 gambe e la versione 2 zampe. La versione a 3 zampe è quella che riceve la maggior parte dell'attenzione, ed è non quella che si desidera utilizzare.

La buona notizia è che la versione a due zampe fa esattamente ciò che si desidera, consente a un'applicazione di concedere l'accesso a un altro tramite una chiave segreta condivisa (molto simile al modello di servizio Web di Amazon, si utilizzerà l'HMAC- Metodo di firma SHA1) o tramite un sistema a chiave pubblica/privata (utilizzare il metodo di firma: RSA-SHA1). La brutta notizia è che non è ancora supportato così bene come la versione a 3 zampe, quindi potresti dover fare un po 'più di lavoro di quanto potresti dover fare adesso.

Fondamentalmente, OAuth a 2 vie specifica solo un modo per "firmare" (calcolare un hash su) diversi campi che includono la data corrente, un numero casuale chiamato "nonce" e i parametri della richiesta. Questo rende molto difficile per impersonare richieste al tuo servizio web.

OAuth sta lentamente ma sicuramente diventando uno standard accettato per questo genere di cose: a lungo termine sarai migliore se lo abbraccerai perché le persone potranno sfruttare le varie librerie disponibili per farlo.

È più elaborato di quello che inizialmente vorrebbe entrare, ma la buona notizia è che molte persone hanno trascorso molto tempo in modo da sapere che non si è dimenticato nulla. Un grande esempio è che molto recentemente Twitter ha individuato un vuoto nella sicurezza OAuth che la comunità sta attualmente lavorando alla chiusura. Se avessi inventato il tuo sistema, dovresti scoprire tutte queste cose da solo.

Buona fortuna!