Жетон отзыва привратника

Я внедряю OAuth 2 в свое приложение, и у меня уже есть токен входа/обновления, но у меня возникают проблемы с выходом из системы.

У меня есть этот набор маршрутов, генерируемых 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

Что я хочу сделать, так это отозвать токен на сервере, поэтому я думаю, что служба, которую я должен вызвать, это «УДАЛИТЬ/авторизовать», верно? но я пробую много разных способов использовать эти услуги, и я только получаю ошибки.

Кстати, я не знаю, правильно ли отозвать токен на сервере или удалить его только из приложения?

PS: я использую AFNetworking 2 в iOS 7 для своего клиента.


ruby-on-rails oauth-2.0 doorkeeper
person FxckDead    schedule 21.11.2013    source источник
comment
Проголосовал за этот вопрос. Мой клиент забудет токен и обновит токен без проблем. Только на сервере все еще есть аутентифицированный пользователь. Когда клиент снова аутентифицируется, он получает этого пользователя. Скорее всего, это что-то, что я делаю неправильно на стороне сервера. Тем не менее, кажется, что сервер должен быть проинформирован о том, что токен больше не должен учитываться.   -  person Douglas Lovell    schedule 26.02.2014

Ответы (2)


arrow_upward
5
arrow_downward

Это на самом деле не отвечает на вопрос, но предоставляет соответствующую информацию.

У меня была проблема, когда привратник проверял любую комбинацию пользователя/пароля в запросе на предоставление учетных данных пароля владельца ресурса после выполнения какой-либо предварительной авторизации для действительной комбинации пользователя/пароля. Сценарий был:

  • клиент получает авторизацию, используя действительное имя пользователя и пароль
  • клиент сбрасывает/забывает токен авторизации, чтобы завершить авторизацию
  • клиент может получить новую авторизацию, используя любое имя пользователя и пароль, авторизуемый для первоначального пользователя.

Оказалось, что Warden удерживает авторизованного пользователя в сеансе, а мой клиент iOS с радостью поддерживает сеанс для меня.

Я решил эту проблему, заставив надзирателя немедленно выйти из системы после аутентификации. Это работает, потому что по авторизованному запросу OAuth получает текущего пользователя, сохраненного с токеном авторизации. Пользователь не должен находиться в сеансе.

Следующее взято из config/initializers/doorkeeper.rb. Последние две строки выполняют выход после авторизации.

# 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
person Douglas Lovell    schedule 26.02.2014
comment
Я почти уверен, что это можно исправить, указав Warden не сохранять аутентифицированного пользователя в сеансе. user = request.env["warden"].authenticate!(scope: :user, store: false) см.: github.com/doorkeeper-gem/doorkeeper/issues/< /а> - person stevenharman; 12.07.2017
comment
Поскольку при этом пользователь выходит из системы во время входа в систему, токен не может быть обновлен (неявное предоставление, когда вы не получаете токен обновления), и пользователь должен снова войти в систему через пару часов (когда токен истекает). Я хочу выйти из системы этого пользователя, когда пользователь нажимает «Выйти». Обычный session#destroy не работает! Даже пост-звонок сделать warden.logout не получается! Что делать в этом случае? - person Sagar Ranglani; 10.05.2020
comment
@SagarRanglani спасибо за ваш вопрос. Я больше не использую это программное обеспечение и не участвую ни в каких приложениях, использующих OAuth. На первый взгляд, мой ответ будет заключаться в том, что вы ссылаетесь в своем комментарии на отдельную, не связанную с этим проблему. Обновление токена — это другой аспект использования OAuth. В любом случае я не могу сказать об актуальности этого вопроса SO и ответов на предлагаемые в настоящее время решения OAuth. - person Douglas Lovell; 02.06.2020

arrow_upward
1
arrow_downward

Если я правильно понял, проблема в том, что 1) пользователь переходит в клиентское приложение, нажимает «Войти в систему» ​​2) клиентские приложения получают аутентификацию с сервера oauth. в это время у пользователя запрашивается имя пользователя/пароль 3) пользователь нажимает кнопку «Выход» в клиентском приложении 4) пользователь снова нажимает «Войти» в клиентском приложении, и он автоматически регистрирует его, используя старый аутентифицированный токен, а не запрашивая имя пользователя и пароль снова, что является что ты хочешь.

Если это ваша проблема, она связана с файлами cookie. Проверяйте файлы cookie, отправляемые в каждом запросе. В моем случае мне пришлось добавить строку

cookies.delete '_oauth_server_name_session'

и тогда это работало. Вы можете сначала подтвердить, что это проблема с файлами cookie, потому что, если вы переключите браузер (или перейдете в режим инкогнито), этого не произойдет.

person Eugene G    schedule 29.07.2015