OAuth: memorizzazione del token di accesso e del segreto

Question

Abbiamo un numero di client che utilizza la nostra API per alimentare i loro siti web.

Ho iniziato una conversazione al lavoro sull'utilizzo di OAuth per effettuare chiamate API autenticate. Avremo flussi a due, tre e tre gambe.

Per il flusso a tre gambe, non è ancora stato raggiunto un consenso su come memorizzare il token di accesso e il segreto.

L'approccio comune a questo problema consiste nell'avere che i client archivino il token di accesso e il segreto nel proprio DB, ma ciò è fuori questione poiché i client non desiderano gestire le modifiche al codice e i problemi di implementazione.

Le altre opzioni che stiamo considerando:

1) Salvare il token di accesso e segreta in un cookie

2) li Salvataggio nella sessione.

Non sono sicuro se una di queste sia una buona idea. Qualcuno ha qualche suggerimento?

Grazie.

Answer 1

Suppongo che tu stia parlando del tipico tipo di installazione "Fornitore di servizi", "Consumatore" e "Utente". Non so se sarai in grado di implementare oAuth a tre vie se i tuoi Consumatori (cliente) si rifiutano di apportare modifiche.

La sessione e i cookie funzionano per il salvataggio di token, ma il problema è che sono i tuoi clienti (i tuoi clienti) che devono salvarli, non tu. Le chiamate alla tua API stanno accadendo sul back-end e quindi non ci sono sessioni o cookie reali disponibili all'interno di quell'ambito. Se stai facendo solo chiamate JavaScript, forse funziona, ma anche in questo caso solitamente le chiamate vengono fatte tramite un proxy per non avere problemi di scripting tra domini.

In entrambi i casi, se i token vengono memorizzati nella sessione o nei cookie, saranno chiavi "temporanee" e l'Utente dovrà eseguire nuovamente l'autenticazione al termine della sessione o dei cookie. Ma non c'è nulla di sbagliato in ciò che riguarda le specifiche di oAuth, a patto che gli utenti non si preoccupino della re-autenticazione.

È possibile fare riferimento Sample app for .NET written using MVC 5 Razor engine

Answer 2

come Jason detto che non è possibile per l'applicazione consumer per rendere le richieste autenticate se non memorizzano i gettoni necessari per l'autenticazione - li possono archiviare in qualsiasi modo che vogliono, ma questo è una parte necessaria dell'equazione. Può essere un filesystem, memcache, database, memoria.

L'unico modo che vedo per utilizzare i cookie per la memorizzazione di questi è per l'applicazione consumer per impostare queste credenziali di token come cookie nel browser dell'utente e l'utente per inviarli al consumatore ad ogni richiesta - tuttavia questo sembra assurdo come prima, l'applicazione consumer dovrà di nuovo apportare modifiche al proprio codice per gestirlo, e in secondo luogo, le chiavi segrete dei token e dei token voleranno in modo ridondante sulla rete e sul browser dell'utente, che può essere un buco di sicurezza se l'utente stesso decide di fare hacking.

Answer 3

Ho avuto lo stesso problema quando ho implementato oauth a 3 gambe. Ho utilizzato la mia applicazione online su Google App Engine & utilizzato Google DataStore per l'archiviazione dei token di accesso.

Tuttavia, la quota menziona here per la memorizzazione dei dati & richieste di lancio! È l'unica limitazione durante l'utilizzo di Google App Engine!

Answer 4

circa 1) Salvare il token di accesso e segreta in un cookie

considerano il vostro cliente in un internet cafè e cosa succede dopo che lui pretende cancellare i cookie e persona copie prossimi queste informazioni?

mi piacerebbe andare per DB o PHP sessione