Doorkeeper Revoke Token

Question

Sto implementando OAuth 2 nella mia applicazione, e ho già Accedi/Aggiorna token ma ho qualche problema con il logout.

ho questo insieme di percorsi genera da Doorkeeper:

Routes for Doorkeeper::Engine: 
      authorization GET /authorize(.:format)     doorkeeper/authorizations#new 
      authorization POST /authorize(.:format)     doorkeeper/authorizations#create 
      authorization DELETE /authorize(.:format)     doorkeeper/authorizations#destroy 
        token POST /token(.:format)      doorkeeper/tokens#create 
      applications GET /applications(.:format)    doorkeeper/applications#index 
         POST /applications(.:format)    doorkeeper/applications#create 
     new_application GET /applications/new(.:format)   doorkeeper/applications#new 
     edit_application GET /applications/:id/edit(.:format)  doorkeeper/applications#edit 
      application GET /applications/:id(.:format)   doorkeeper/applications#show 
         PUT /applications/:id(.:format)   doorkeeper/applications#update 
         DELETE /applications/:id(.:format)   doorkeeper/applications#destroy 
authorized_applications GET /authorized_applications(.:format)  doorkeeper/authorized_applications#index 
authorized_application DELETE /authorized_applications/:id(.:format) doorkeeper/authorized_applications#destroy 

Quello che voglio fare è revocare un gettone nel server, quindi credo che il servizio che devo chiamare è "DELETE/autorizzare" a destra ? ma provo un sacco di modi diversi per consumare questi servizi e mi limito a correggere errori.

A proposito, non so se è corretto revocare il token nel server o solo cancellarlo dall'applicazione?

PS: sto utilizzando AFNetworking 2 in iOS 7 per il mio client.

Answer 1

Questo in realtà non risponde alla domanda, ma fornisce informazioni correlate.

Avevo il problema per cui il portiere avrebbe convalidato qualsiasi combinazione utente/password su una richiesta di sussidio per le credenziali delle password del proprietario di risorse dopo aver effettuato un'autorizzazione preventiva a una combinazione utente/password valida. Scenario era:

• cliente ottiene l'autorizzazione utilizzando il nome utente e una password validi
• client reset/dimentica autorizzazione token al fine di porre fine all'autorizzazione
• cliente può ottenere una nuova autorizzazione utilizzando qualsiasi nome utente e password, autorizza l'utente originale.

Questa si è rivelata Warden mantenere l'utente autorizzato in una sessione, e il mio cliente iOS felicemente mantenendo la sessione per me.

Ho risolto questo problema facendo in modo che il gestore annulli l'utente dopo l'autenticazione. Funziona perché, su una richiesta autorizzata, OAuth ottiene l'utente corrente memorizzato con il token di autorizzazione. Non ha bisogno di avere l'utente in una sessione.

Quanto segue proviene da config/initializers/doorkeeper.rb. Le ultime due righe eseguono la disconnessione dopo l'autorizzazione.

# called for Resource Owner Password Credentials Grant 
    resource_owner_from_credentials do 
    request.params[:user] = {:email => request.params[:username], :password => request.params[:password]} 
    request.env["devise.allow_params_authentication"] = true 
    user = request.env["warden"].authenticate!(:scope => :user) 
    env['warden'].logout 
    user 
end 

Answer 2

Se ho correttamente il problema è 1) L'utente va a l'applicazione client, scatti il ​​login applicazioni 2) client ottiene l'autenticazione OAuth dal server. all'utente è richiesto username/password in questo momento 3) l'utente fa clic di logout nell'applicazione client 4) i clic dell'utente eseguono di nuovo l'accesso all'applicazione client e lo firmeranno automaticamente utilizzando il vecchio token autenticato invece di chiedere nome utente e pw di nuovo, che è quello che vuoi

Se questo è il tuo problema, ha a che fare con i cookie. Controlla i cookie inviati in ogni richiesta. Nel mio caso, ho dovuto aggiungere una linea

cookies.delete '_oauth_server_name_session'

e ha funzionato poi. Puoi confermare che si tratta di un problema relativo ai cookie in primo luogo perché se cambi browser (o vai in modalità in incognito) ciò non accadrà.