Дверные жетоны обновления не истекают при повторном использовании - PullRequest
Новая
       45

Дверные жетоны обновления не истекают при повторном использовании

0 голосов
/ 07 октября 2019

Я использую Doorkeeper 5.2.1, и я ознакомился с документами Doorkeeper по токенам обновления , прочитал несколько проблем GitHub и запросы на получение, связанные с токенами обновления, в частности здесь и здесь .

Из того, что я извлек из этих разговоров и прочтения спецификации (и документов и сообщений, ссылающихся на спецификацию , следующие утверждения верны:

  • Токены обновления являются долгоживущими (в отличие от токенов доступа, срок действия которых обычно истекает после относительно короткого TTL)
  • Сервер авторизации МОЖЕТ реализовать отзыв
  • Doorkeeper реализует отзыв токенов обновления на некотором основании (хотя мне не ясно, что, продолжайте читать)

Я запутался, хотя, основываясь на этом запросе на получение , которыйреализует истечение срока действия маркера обновления после того, как «токен доступа, созданный с помощью этого маркера обновления, успешно используется один раз». Откуда Doorkeeper узнает, если я сделал запрос API с этимуспешно обработать токен? Это мой API, который разрабатывает логику авторизации на основе этого токена доступа. Doorkeeper не зависит от того, были ли мои запросы API успешными или нет. Однако я интерпретировал это как означающее, что если блок resource_owner_authenticator возвращает пользователя, это может означать успешное использование. Тем не менее, я не обнаружил, что этот токен истекает успешно. (См. Мою спецификацию ниже.)

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

Тем не менее, я пытаюсь все это проработать в своем спецификационном файле, и у меня возникает проблема, из-за которой не представляется, что токен обновления отменен, даже если он используется несколько раз или(«токен обновления A») повторно используется после также используется токен обновления («токен B»), который возвращается с токеном доступа, который используется для генерации токена обновления A. Мой файл спецификаций сделает это более понятным: 

describe 'OAuth flow' do
  # ...
  describe 'refresh tokens' do

    # ...
    context 'when attempting reuse of a refresh token' do
      before do
        redirect_uri = 'https://localhost:3002'

        # ivars necessary brecause plaintext tokens/secrets are only available upon creation of the object
        @client = Doorkeeper::Application.create(name: 'foo', uid: 'bar', redirect_uri: redirect_uri, scopes: 'project_index')
        @secret = @client.plaintext_secret
        @grant = Doorkeeper::AccessGrant.create(resource_owner_id: user.id, organization_id: org.id, application_id: @client.id, scopes: 'project_index', expires_in: 600, redirect_uri: redirect_uri)
        @code = @grant.plaintext_token
      end

      it 'revokes the initial refresh token' do
        # Get an initial access token and refresh token
        post "/oauth/token?client_id=#{@client.uid}&client_secret=#{@secret}&code=#{@code}&grant_type=authorization_code&redirect_uri=#{@client.redirect_uri}&scope=project_index"
        expect(response.status).to eq(200)

        # Use refresh token to get a new access token
        previous_refresh_token = JSON.parse(response.body)['refresh_token']

        post "/oauth/token?client_id=#{@client.uid}&client_secret=#{@secret}&code=#{@code}&grant_type=refresh_token&refresh_token=#{previous_refresh_token}&redirect_uri=#{@client.redirect_uri}&scope=project_index"
        expect(response.status).to eq(200)
        json_body = JSON.parse(response.body)
        new_access_token = json_body['access_token']
        new_refresh_token = json_body['refresh_token']

        # Use the new access token successfully
        get "/api/v1/projects?access_token=#{new_access_token}"
        expect(response.status).to eq(200)

        # Use the new refresh token to get yet another access token
        post "/oauth/token?client_id=#{@client.uid}&client_secret=#{@secret}&code=#{@code}&grant_type=refresh_token&refresh_token=#{new_refresh_token}&redirect_uri=#{@client.redirect_uri}&scope=project_index"
        expect(response.status).to eq(200)

        # Attempt reuse of the first refresh token
        post "/oauth/token?client_id=#{@client.uid}&client_secret=#{@secret}&code=#{@code}&grant_type=refresh_token&refresh_token=#{previous_refresh_token}&redirect_uri=#{@client.redirect_uri}&scope=project_index"
        expect(response.status).to eq(400)

        # ^^^ fails, response is 200 and a new access token and refresh token are generated
      end
    end
  end

  # ...
end

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

У меня вопрос, с Doorkeeper, при каких обстоятельствах аннулируется токен обновления?

...