Come impongo la scadenza del token di accesso OAuth2 con DotNetOpenAuth

Question

Sto implementando il server di autorizzazione/risorsa OAuth2 basato su DotNetOpenAuth. Il mio server pubblicherà i token di accesso con una durata molto lunga. Questi token saranno utilizzati dai dispositivi iOS. Il flusso, a mio modo di vedere, è così, 1) a un utente viene chiesto di inserire il nome utente/password sul dispositivo iOS 2) viene richiesto un token di accesso con tipo di concessione di credenziali Password proprietario risorsa 3) il token è concesso e memorizzato sul dispositivo iOS per uso futuro.

Ora di tanto in tanto gli utenti vengono disabilitati. Vorrei revocare il token allo stesso tempo. Come faccio a fare questo? I sospetto che ho bisogno di utilizzare il metodo ICryptoKeyStore.RemoveKey per quello, ma non sono sicuro di come trovare la chiave da rimuovere.

Nota 1: in futuro il server verrà utilizzato da applicazioni Web di terzi.

Nota 2: il requisito di avere un tipo di concessione di credenziali Password proprietario risorse deriva dal fatto che è stato deciso che l'implementazione del reindirizzamento del browser sul dispositivo iOS non vale il tempo.

Update 1 Alcuni scavi nel codice sorgente suggeriscono che DotNetOpenAuth non supporta questa possibilità di forzare scadenza del token fuori dalla scatola. Inoltre nella vita standard dell'implementazione del token non viene nemmeno verificato. Per quanto posso vedere il calss è responsabile per questo è StandardAccessTokenAnalyzer e ignora le proprietà Lifetime e UtcCreationDate. Inoltre, non sembra che la classe standard ResourceServer abbia un accesso al database codificato, la validità del token verificata solo dal contenuto del token, quindi sembra che se ho bisogno di aggiungere la possibilità di scadere i token ho bisogno di collegare lo ResourseServer al database stesso . Mi sto perdendo qualcosa?

Update 2 Credo di avere trovato qui la risposta: https://groups.google.com/forum/#!topic/dotnetopenid/aLabu1ujkt4 Non è quello che speravo e ho ancora un paio di unclarities. Ad esempio, Andrew ha scritto:

classe personalizzata quindi potrebbe richiedere un token di accesso, quindi utilizzare una richiesta HTTP privato al server di autorizzazione per verificare la continua validità del token.

Non è chiaro come questa verifica può accadere, visto che AccessToken non include Autorizzazione Id. Ciò può rendere difficile la ricerca del record di autorizzazione di destinazione. In teoria, possiamo provare a cercare la combinazione di client, utente e tempo di emissione, ma per quanto posso vedere non c'è alcuna garanzia che questi saranno unici.

Answer 1

Ora di volta in volta gli utenti ottengono disabilitato. Vorrei revocare il token allo stesso tempo. Come faccio a fare questo? Ho il sospetto che dovrei usare il metodo ICryptoKeyStore.RemoveKey per quello, ma non sono sicuro di come trovare la chiave da rimuovere.

È possibile revocare token revocando l'autorizzazione dietro il token. Questo in genere significa che elimini una voce nella tabella delle autorizzazioni del tuo database. L'effetto che deve avere è che l'implementazione di IAuthorizationServerHost.IsAuthorizationValid restituirà false per questa autorizzazione.

Questo non revocare immediatamente token di accesso, ma blocca il client dal rinfrescante scaduto token di accesso.Pertanto, finché i token di accesso hanno una durata ragionevolmente breve (un'ora o meno), l'account disattivato di un utente significa che tutti gli accessi client termineranno entro un'ora.

Nota 2: il requisito di avere un tipo di concessione di credenziali Password proprietario risorse deriva dal fatto che è stato deciso che l'implementazione del reindirizzamento del browser su dispositivo iOS non vale il tempo.

È la tua app. Ma esorto tutti a utilizzare il corretto flusso di reindirizzamento del browser. È probabile che l'utente abbia già effettuato l'accesso al tuo server sul browser del dispositivo in modo che possa evitare di inserire le proprie credenziali in questo modo, migliorando i tassi di conversione. Inoltre, è più probabile che gli utenti si fidino del browser che richiede le proprie credenziali rispetto a un'app del dispositivo. Almeno lo spero.

Tra l'altro, il proprietario della risorsa tipo di password concessione rischia di non essere supportata per i clienti non-autenticazione (TBD), che ha installato le applicazioni dei dispositivi sarà in genere. Quindi potresti essere costretto a usare un tipo di sovvenzione differente.

Update 1 Alcuni scavi nel codice sorgente suggeriscono che DotNetOpenAuth non supporta questa possibilità di forzare scadenza del token fuori dalla scatola. Inoltre nella vita di implementazione standard del token non viene nemmeno verificato. Per quanto posso vedere il calss è responsabile per questo è StandardAccessTokenAnalyzer e ignora le proprietà Lifetime e UtcCreationDate.

DotNetOpenAuth fa assegno e rifiutare token di accesso scaduti. Non è solo in quella classe. Viene controllato nel codice che deserializza i token di accesso.

Inoltre non sembra che la classe ResourceServer norma è codificato alcun accesso al database, la validità del token controllato dal contenuto del token unico, così sembra che se ho bisogno di aggiungere capacità per scadere i gettoni che ho bisogno di filo up il ResourseServer al database me stesso. Mi sto perdendo qualcosa?

Lei ha ragione che la classe ResourceServer non richiede alcun accesso al database, perché token di accesso si presume valida per tutta la loro vita (sono non revocabile per impostazione predefinita). Questo è il motivo per cui si consiglia una vita breve del token di accesso. Questo non è così lontano come si potrebbe pensare. Ad esempio, l'autenticazione basata su form ASP.NET, che è molto probabile che utilizzi già, si basa sullo stesso modello: autentifica l'utente una sola volta, invia il database per un controllo delle credenziali, quindi invia un cookie HTTP crittografato e firmato all'agente utente. Da quel momento in poi, il database non viene colpito su ogni richiesta HTTP in arrivo - la firma del cookie viene convalidata e quindi ritenuta valida fino alla scadenza del cookie. Lo stesso principio Tranne che nel caso dei cookie HTTP, c'è un che scorre il timeout, in modo che finché l'utente rimane attivo sul sito, non devono mai riautenticare. Con i token di accesso OAuth 2, scadono indipendentemente dal modo in cui vengono utilizzati attivamente, forzando un aggiornamento del token che può quindi essere rifiutato per bloccare l'accesso.

Non è chiaro come questa verifica può accadere, dato che access token non include Autorizzazione Id. Ciò può rendere difficile la ricerca del record di autorizzazione di destinazione. In teoria, possiamo provare a cercare la combinazione di client, utente e tempo di emissione, ma per quanto posso vedere non c'è alcuna garanzia che questi saranno unici.

E 'vero alcun ID è incluso, ma la tupla di client-user-Data di Rilascio-ambito di applicazione dovrebbe essere unico, come la vostra tabella di autorizzazione dovrebbe avere un vincolo univoco su di esso in quanto avendo i duplicati non avrebbe senso. Inoltre, se non fossero unici, solo la presenza di qualsiasi record con quella tupla suggerisce che l'autorizzazione è valida.

Spero che questo aiuti.