В разделе 4.2 проекта протокола OAuth 2.0 указано, что сервер авторизации может возвращать как access_token (который используется для аутентификации с ресурсом), так и refresh_token, который используется исключительно для создания нового access_token:
https://tools.ietf.org/html/rfc6749#section-4.2
Почему есть оба? Почему бы просто не сделать access_token последним до тех пор, пока refresh_token и не иметь refresh_token?
Идея токенов обновления заключается в том, что если токен доступа скомпрометирован, потому что он недолговечен, у злоумышленника есть ограниченное окно, в котором он будет злоупотреблять им.
Обновить токены, если они скомпрометированы, бесполезны, потому что злоумышленник требует идентификатор клиента и секрет в дополнение к токере обновления, чтобы получить токен доступа.
Сказав это, поскольку каждый вызов как сервера авторизации, так и сервера ресурсов выполняется через SSL - включая исходный идентификатор клиента и секрет, когда они запрашивают токены доступа/обновления - я не уверен как токен доступа более "компрометируется", чем долговечный токен обновления и клиентская/секретная комбинация.
Это, конечно, отличается от реализаций, где вы не контролируете серверы авторизации и ресурсов.
Вот хороший поток, говорящий об использовании токенов обновления: Архивы OAuth.
Цитата из вышеизложенного, говоря о целях безопасности токена обновления:
Обновить токены... смягчает риск долговременного утечки access_token (параметр запроса в файле журнала на незащищенном сервере ресурсов, бета-версии или плохо закодированном сервере ресурсов, клиент JS SDK на сайте, отличном от https, который помещает access_token в файле cookie и т.д.)
Ссылка на обсуждение, предоставленная Catchdave, содержит еще одну действительную точку (оригинальная,недействительная ссылка) , сделанную Диком Хардтом, которую, я считаю, стоит упомянуть здесь в дополнение к тому, что было написано выше:
Мое воспоминание о фишках обновления было для безопасности и аннулирования. & Lt;...>
Отзыв:, если токен доступа самодостаточен, авторизацию можно отозвать, не выдавая новые токены доступа. Ресурсу не нужно запрашивать сервер авторизации, чтобы узнать, является ли токен доступа действительным. Это упрощает проверку токена доступа и упрощает масштабирование и поддержку нескольких серверов авторизации. Существует окно времени, когда токен доступа действителен, но авторизация отменена.
Действительно, в ситуации, когда сервер ресурсов и сервер авторизации являются одним и тем же объектом, и когда соединение между пользователем и любым из них (как правило) одинаково безопасно, нет особого смысла хранить токен обновления отдельно от токена доступа.
Хотя, как уже упоминалось в цитате, еще одна роль токенов обновления заключается в том, чтобы гарантировать, что токен доступа может быть отозван пользователем в любое время (например, через веб-интерфейс в его профилях), сохраняя при этом систему масштабируемой в то же время..
Как правило, токены могут быть случайными идентификаторами, указывающими на конкретную запись в базе данных Сервера, или они могут содержать всю информацию в себе (безусловно, эта информация должна быть подписана, например, с помощью MAC).
Как должна работать система с долгоживущими токенами доступа
Сервер позволяет Клиенту получить доступ к данным Пользователя в рамках заранее определенного набора областей путем выдачи токена. Поскольку мы хотим сохранить токен отзывным, мы должны сохранить в базе данных токен вместе с установленным или снятым флагом "отзывано" (в противном случае, как бы вы сделали это с автономным токеном?) База данных может содержать до len(users) x len(registered clients) x len(scopes combination) записи. Затем каждый запрос API должен попадать в базу данных. Хотя запросы к такой базе данных, выполняющие O (1), довольно тривиальны, сама точка отказа может отрицательно повлиять на масштабируемость и производительность системы.
Как должна работать система с долгоживущим токеном обновления и недолговечным токеном доступа
Здесь мы выдаем два ключа: токен случайного обновления с соответствующей записью в базе данных и подписанный токен автономного доступа, содержащий, среди прочего, поле метки времени истечения.
Поскольку маркер доступа является автономным, нам не нужно обращаться к базе данных вообще, чтобы проверить его действительность. Все, что нам нужно сделать, это декодировать токен и проверить подпись и отметку времени.
Тем не менее, нам все еще нужно хранить базу данных токенов обновления, но количество запросов к этой базе данных, как правило, определяется сроком жизни токена доступа (чем больше срок жизни, тем ниже скорость доступа).
Чтобы отозвать доступ Клиента у определенного Пользователя, мы должны пометить соответствующий токен обновления как "отозванный" (или полностью удалить его) и прекратить выпуск новых токенов доступа. Очевидно, что есть окно, во время которого токен обновления был отозван, но его токен доступа все еще может быть действительным.
Компромисс
Токены обновления частично устраняют SPoF (единую точку отказа) базы данных токенов доступа, но у них есть некоторые очевидные недостатки.
Окно". Промежуток времени между событиями "пользователь отменяет доступ" и "доступ гарантированно будет отменен".
Усложнение клиентской логики.
без обновления токена
с токеном обновления
Я надеюсь, что этот ответ имеет смысл и помогает кому-то принять более продуманное решение. Хочу также отметить, что некоторые известные провайдеры OAuth2, включая github и foursquare, используют протокол без токенов обновления и, похоже, довольны этим.
Несмотря на все замечательные ответы, приведенные выше, я, как магистр безопасности и программист, ранее работавший в eBay, когда я изучал защиту покупателей и мошенничество, могу сказать, что отдельный токен доступа и токен обновления имеют лучший баланс между преследованием пользователя с частым именем пользователя./Ввод пароля и сохранение полномочий на аннулирование доступа к возможному злоупотреблению вашим сервисом.
Думайте о сценарии как это. Вы выдаете пользователю токен доступа на 3600 секунд и обновляете токен намного дольше, чем за один день.
Пользователь - хороший пользователь, он дома и включает/выключает ваш сайт, совершая покупки и поиск на своем iPhone. Его IP-адрес не меняется и имеет очень низкую нагрузку на ваш сервер. Как 3-5 запросов страниц каждую минуту. Когда его 3600 секунд на токене доступа закончились, ему требуется новый с токеном обновления. Мы на стороне сервера проверяем его историю активности и IP-адрес, думаем, что он человек и ведет себя сам. Мы даем ему новый токен доступа для продолжения использования нашего сервиса. Пользователю не нужно будет снова вводить имя пользователя/пароль до тех пор, пока он не достигнет одного дня жизни маркера обновления.
Пользователь - неосторожный пользователь. Он живет в Нью-Йорке, США, закрыл свою вирусную программу и был взломан хакером в Польше. Когда хакер получил токен доступа и обновил токен, он пытается выдать себя за пользователя и использовать наш сервис. Но после истечения срока действия токена доступа с коротким сроком действия, когда хакер пытается обновить токен доступа, мы на сервере заметили резкое изменение IP-адреса в истории поведения пользователя (эй, этот парень входит в систему в США и теперь обновляет доступ в Польше только после 3600-х годов???). Мы прекращаем процесс обновления, лишаем законной силы токен обновления и предлагаем ввести имя пользователя/пароль еще раз.
Пользователь является злонамеренным пользователем. Он намерен злоупотреблять нашим сервисом, вызывая 1000 раз наш API каждую минуту, используя робота. Он мог делать это до 3600 секунд спустя, когда он попытался обновить токен доступа, мы заметили его поведение и подумали, что он не человек. Мы отклоняем и прекращаем процесс обновления и просим его снова ввести имя пользователя/пароль. Это может потенциально сломать его автоматический поток робота. По крайней мере, ему неудобно.
Вы можете видеть, что токен обновления работал отлично, когда мы пытаемся сбалансировать нашу работу, пользовательский опыт и потенциальный риск кражи токена. Ваша сторожевая собака на стороне сервера может проверять больше, чем изменение IP, частоту вызовов API, чтобы определить, является ли пользователь хорошим пользователем или нет.
Еще одно слово: вы также можете попытаться ограничить контроль ущерба от украденного токена/злоупотребления обслуживанием, применяя для каждого вызова API базовый IP-сторож или любые другие меры. Но это дорого, так как вы должны читать и записывать записи о пользователе и замедлять реакцию вашего сервера.
Ни один из этих ответов не доходит до основной причины обновления токенов. Очевидно, что вы всегда можете получить новую пару токен-токен/обновление-токен, отправив ваши учетные данные на сервер auth - вот как вы их получите в первую очередь.
Таким образом, единственная цель токена обновления - ограничить использование учетных данных клиента, отправляемых по проводке в службу auth. Чем короче ttl токена доступа, тем чаще учетные данные клиента должны будут использоваться для получения нового токена доступа, и, следовательно, больше возможностей злоумышленникам, чтобы скомпрометировать учетные данные клиента (хотя это может быть очень сложно в любом случае, если для их отправки используется асимметричное шифрование). Поэтому, если у вас есть одноразовый токен обновления, вы можете сделать ttl токенов доступа произвольно малыми, не ставя под угрозу учетные данные клиента.
Чтобы устранить некоторую путаницу, вам нужно понять роли секретного ключа и пароль пользователя, который очень отличается.
Клиент - это приложение/веб-сайт/программа/..., поддерживаемый сервером, который хочет аутентифицировать пользователя с помощью сторонней службы проверки подлинности. Секрет клиента - это (случайная) строка, известная как для этого клиента, так и для сервера аутентификации. Используя этот секрет, клиент может идентифицировать себя с сервером аутентификации, получая авторизацию для запроса токенов доступа.
Чтобы получить токен первичного доступа и токен обновления, требуется следующее:
Чтобы получить обновленный токен доступа, клиент использует следующую информацию:
Это ясно показывает разницу: при обновлении клиент получает авторизацию для обновления токенов доступа с помощью своего секретного ключа клиента и, таким образом, может повторно аутентифицировать пользователя, используя токен обновления, вместо пароля пользователя ID+. Это фактически не позволяет пользователю повторно ввести свой пароль.
Это также показывает, что потеря токена обновления не проблема, потому что идентификатор клиента и секрет неизвестны. Он также показывает, что сохранение секретности клиента и секретности клиента жизненно важно.
Этот ответ от Джастина Ричера через стандартный список электронной почты OAuth 2. Это отправлено с его разрешения.
Срок действия токена обновления зависит от сервера авторизации (AS) - они могут истекать, аннулироваться и т.д. Разница между токеном обновления и токеном доступа - это аудитория: токен обновления только возвращается к сервер авторизации, токен доступа переходит на сервер ресурсов (RS).
Кроме того, просто получение токена доступа не означает, что пользователи вошли в систему. Фактически, пользователь может даже не быть там, что на самом деле является предполагаемым вариантом использования токена обновления. Обновление токена доступа даст вам доступ к API для имени пользователя, он не скажет вам, есть ли там пользователи.
OpenID Connect не просто дает вам информацию о пользователе из токена доступа, но также дает токен идентификатора. Это отдельный фрагмент данных, который адресован самому клиенту, а не AS или RS. В OIDC вы должны только считать, что кто-то фактически "вошел в систему" по протоколу, если вы можете получить новый токен идентификатора. Освежить его вряд ли будет достаточно.
Для получения дополнительной информации, пожалуйста, прочитайте http://oauth.net/articles/authentication/
Клиенты могут быть скомпрометированы разными способами. Например, мобильный телефон может быть клонирован. Наличие истечения срока действия токена означает, что клиент вынужден повторно аутентифицироваться на сервере авторизации. Во время повторной аутентификации сервер авторизации может проверять другие характеристики (IOW выполняет адаптивное управление доступом).
Резервные маркеры разрешают только повторную аутентификацию клиента, где при повторном авторизации заставляет диалог с пользователем, о котором многие указали, что они предпочитают не делать.
Обновить токены, по существу, в том же месте, где обычным веб-сайтам может быть предложено периодически повторно аутентифицировать пользователей через час или около того (например, банковский сайт). В настоящее время он мало используется, поскольку большинство социальных веб-сайтов не повторно аутентифицируют веб-пользователей, поэтому зачем они повторно аутентифицировать клиента?
Для дальнейшего упрощения ответа BT: используйте токены обновления, когда обычно не требуется, чтобы пользователь снова вводил учетные данные, но все же хочет, чтобы власть могла отменить разрешения (путем отмены токена обновления)
Вы не можете отменить токен доступа, только токен обновления.
Почему бы просто не сделать access_token последним до тех пор, пока refresh_token и у вас нет refresh_token?
В дополнение к отличным ответам, которые другие люди предоставили, есть еще одна причина, по которой нужно использовать токены обновления и их действия с претензиями.
Каждый токен содержит претензии, которые могут включать в себя что-либо от имени пользователя, их ролей или поставщика, создавшего заявку. Когда токен обновляется, эти утверждения обновляются.
Если мы чаще обновляем токены, мы, очевидно, больше напрягаемся в наших службах идентификации, но мы получаем более точные и современные утверждения.
Предположим, вы делаете access_token последним очень долго, и у вас нет refresh_token, так что в один прекрасный день хакер получит это access_token, и он сможет получить доступ ко всем защищенным ресурсам!
Но если у вас есть refresh_token, время access_token в реальном времени короткое, поэтому хакеру сложно взломать ваш access_token, потому что он будет недействительным через короткий промежуток времени.
Access_token может быть восстановлен только с помощью не только refresh_token, но также client_id и client_secret, которых у хакера нет.
Пока токен обновления сохраняется на сервере авторизации. Маркер доступа является автономным, поэтому сервер ресурсов может его проверить, не сохраняя его, что экономит усилия поиска в случае проверки. Еще один момент, отсутствующий в обсуждении, - rfc6749 # page-55
"Например, сервер авторизации может использовать токен обновления вращение, при котором новый токен обновления выдается с каждым доступом ответ обновления токена. Предыдущий токен обновления недействителен, но сохраненный сервером авторизации. Если токен обновления скомпрометированы и впоследствии используются как злоумышленником, так и законный клиент, один из них представит недействительное обновление токен, который будет информировать сервер авторизации о нарушении."
Я думаю, что весь смысл использования токена обновления - это то, что даже если злоумышленнику удается получить токен обновления, идентификатор клиента и секретную комбинацию. С последующими вызовами получить новый токен доступа от злоумышленника можно отслеживать в случае, если каждый запрос обновления обновляется с помощью нового токена доступа и обновляет токен.
Этот ответ был составлен с помощью двух старших разработчиков (Джон Брайтон и Дэвид Дженнес).
Основной причиной использования токена обновления является уменьшение поверхности атаки.
Предположим, что нет ключа обновления, и давайте рассмотрим этот пример:
Здание имеет 80 дверей. Все двери открываются одним и тем же ключом. Ключ меняется каждые 30 минут.
Если я хакер и получу ваш ключ, то по прошествии 30 минут я отправлю его курьеру и получу новый ключ. Я буду в состоянии постоянно открывать все двери независимо от смены ключа.
Вопрос: Сколько хакерских возможностей у меня было за 30 минут против ключа? У меня было 80 возможностей для взлома, каждый раз, когда вы использовали ключ (представьте, что вы делаете сетевой запрос и передаете токен доступа для идентификации себя). Так вот, 80X поверхность атаки.
Теперь давайте рассмотрим тот же пример, но на этот раз давайте предположим, что есть ключ обновления.
Здание имеет 80 дверей. Все двери открываются одним и тем же ключом. Ключ меняется каждые 30 минут. Если я хакер и получу ваш ключ, я могу использовать его в течение 30 минут, но по истечении 30 минут отправка его создателю ключей не имеет значения. Если я это сделаю, то создатель ключей просто скажет, что срок действия ключа истек. Чтобы иметь возможность продлить свой хак, мне пришлось бы взломать курьера для создателя ключей. У курьера есть особый ключ (думайте об этом как токен обновления).
Вопрос: Сколько хакерских возможностей у меня было за 30 минут против курьера? 80? У меня была только 1 возможность взлома. В течение времени курьер общается с создателем ключей. Так что это 1X поверхность атаки. У меня было 80 возможностей взлома ключа, но через 30 минут они оказались бесполезными.
Сервер будет проверять токен доступа на основе учетных данных и подписи (обычно) JWT.
Утечка токена доступа - это плохо, но как только он истекает, он больше не нужен злоумышленнику. Утечка токена обновления намного хуже, но, вероятно, менее вероятна. (Я думаю, что есть вопрос, является ли вероятность утечки токена обновления намного ниже, чем утечка токена доступа, но это идея.)
Дело в том, что токен доступа добавляется к каждому вашему запросу, тогда как токен обновления используется только во время процесса обновления. Так меньше шансов MITM увидеть токен
Частота помогает злоумышленнику. Heartbleed -like потенциальные уязвимости в SSL, потенциальные уязвимости в клиенте и потенциальные уязвимости в сервере делают возможной утечку.
Кроме того, если сервер авторизации отделен от сервера приложений, обрабатывающего другие клиентские запросы, этот сервер приложений никогда не увидит токены обновления. Он будет видеть только токены доступа, которые не будут жить намного дольше.
Отделение хорошо для безопасности.
О каком токене обновления не идет речь?
Возможность обновлять/отзывать уровень доступа с помощью токенов обновления является побочным продуктом выбора использования токенов обновления, в противном случае автономный токен доступа может быть отозван или его уровень доступа изменен после истечения срока действия, и пользователи получают новый токен.
Рассмотрим систему, в которой каждый пользователь связан с одной или несколькими ролями, и каждая роль связана с одной или несколькими правами доступа. Эта информация может быть кэширована для повышения производительности API. Но тогда могут быть изменения в настройках пользователя и ролей (например, может быть предоставлен новый доступ или может быть отменен текущий доступ), и они должны быть отражены в кеше.
Мы можем использовать токены доступа и обновления для этой цели. Когда API вызывается с помощью токена доступа, сервер ресурсов проверяет кеш на права доступа. ЕСЛИ есть какие-либо новые гранты доступа, это не отражается сразу. Как только токен доступа истекает (скажем, через 30 минут), и клиент использует токен обновления для генерации нового токена доступа, кеш может обновляться с обновленной информацией прав доступа пользователя из БД.
Другими словами, мы можем переместить дорогостоящие операции из каждого вызова API с использованием токенов доступа в событие генерации токена доступа с использованием токена обновления.
Сначала клиент аутентифицируется на сервере авторизации, предоставляя разрешение на авторизацию.
Затем клиент запрашивает сервер ресурсов для защищенного ресурса, предоставляя токен доступа.
Сервер ресурсов проверяет токен доступа и предоставляет защищенный ресурс.
Клиент делает запрос защищенного ресурса на сервер ресурсов, предоставляя токен доступа, где сервер ресурсов проверяет его и обслуживает запрос, если он действителен. Этот шаг продолжает повторяться, пока токен доступа не истечет.
Если токен доступа истекает, клиент аутентифицируется на сервере авторизации и запрашивает новый токен доступа, предоставляя токен обновления. Если токен доступа недействителен, сервер ресурсов отправляет клиенту неверный ответ на токен.
Клиент аутентифицируется с помощью сервера авторизации, предоставляя токен обновления.
Затем сервер авторизации проверяет токен обновления, аутентифицируя клиента и выдает новый токен доступа, если он действителен.
Я разработал расширение SAML, WS-Federation и OAuth Tracer для Google Chrome: https://chrome.google.com/webstore/detail/rcfederation-saml-ws-fed/hkodokikbjolckghdnljbkbhacbhpnkb
Используя расширение, вы можете легко отлаживать/отслеживать "сообщения", используемые там протоколами.