Почему OAuth v2 имеет токены доступа и обновления?

ссылка на обсуждение, предоставленная Catchdave, имеет другой довод сделано Диком Хардтом, который, я считаю, стоит упомянуть здесь в дополнение к тому, что было написано выше:

мое воспоминание о токенах обновления было для безопасности и отзыва. <...>

отзыв: если маркер доступа является автономным, авторизация может быть отозвана, не выдавая новые маркеры доступа. Ресурсу не нужно запрашивать сервер авторизации для проверки допустимости маркера доступа.Это упрощает проверку маркеров доступа и упрощает масштабирование и поддержку нескольких серверов авторизации. Есть окно времени, когда маркер доступа действителен, но разрешение аннулируется.

действительно, в ситуации, когда сервер ресурсов и сервер авторизации-это одна и та же сущность, и когда соединение между Пользователем и любым из них (обычно) одинаково безопасно, нет смысла хранить маркер отдельно от маркера доступа.

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

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

как должна работать система с долгоживущими токенами доступа

сервер позволяет клиенту получить доступ к данным пользователя в пределах заданного набора областей путем выдачи жетона. Поскольку мы хотим сохранить токен отзываемым, мы должны сохранить в базе данных токен вместе с флагом "отозван", который устанавливается или отключается (в противном случае, как бы вы это сделали с автономным токеном?) База данных может содержать столько, сколько len(users) x len(registered clients) x len(scopes combination) записей. Затем каждый запрос API должен попасть в базу данных. Хотя довольно тривиально делать запросы к такой базе данных, выполняющей O (1), сама единственная точка отказа может отрицательно повлиять на масштабируемость и производительность системы.

как должна работать система с долгоживущим токеном обновления и кратковременным токеном доступа

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

поскольку маркер доступа является автономным, нам не нужно вообще попадать в базу данных, чтобы проверить ее действительность. Все, что нам нужно сделать, это декодировать маркер и проверить подпись и метку времени.

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

чтобы отозвать доступ клиента у конкретного пользователя, мы должны отметить соответствующий токен обновления как "отозванный" (или удалить его полностью) и прекратить выдачу новых токенов доступа. Очевидно, однако, что есть окно, во время которого токен обновления был отозван, но его токен доступа все еще может быть действительным.

недостатки

обновления частично устранить SPoF (Single Point of Failure) базы данных маркеров доступа, но у них есть некоторые очевидные недостатки.

1. "Окно". Таймфрейм между событиями "пользователь отменяет доступ"и" доступ гарантированно будет отменен".

2. усложнение клиентской логики.

   без маркер

   • отправить запрос API с токеном доступа
   • если маркер доступа является недопустимой, не и просить пользователя повторная аутентификация

   С маркер

   • отправить запрос API с токеном доступа
   • если маркер доступа недействителен, попробуйте обновить его с помощью маркера обновления
   • если запрос обновления проходит, обновите маркер доступа и повторно отправьте первоначальный запрос API
   • если запрос обновления не выполняется, попросите пользователя повторно аутентифицироваться

Я надеюсь, что этот ответ имеет смысл и помогает кто-то, кто примет более продуманное решение. Я хотел бы также отметить, что некоторые известные поставщики OAuth2, включая github и foursquare, принимают протокол без токенов обновления и, похоже, довольны этим.

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

подумайте о сценарии, как этот. Вы выдаете пользователю маркер доступа 3600 секунд и обновить маркер гораздо дольше, как один день.

1. пользователь хороший пользователь, он дома и получает вкл / выкл ваш сайт покупки и поиск на своем iPhone. Его IP-адрес не меняется и имеет очень низкую нагрузку на ваш сервер. Как запрос 3-5 страниц каждую минуту. Когда его 3600 секунд на маркере доступа закончились, ему требуется новый с маркером обновления. Мы, на стороне сервера, проверяем его история активности и IP-адрес, думаю, что он человек и ведет себя. Мы предоставляем ему новый токен доступа для продолжения использования нашего сервиса. Пользователю не нужно будет снова вводить имя пользователя / пароль, пока он не достигнет одного дня жизни самого токена обновления.

2. пользователь неосторожное пользователей. Он живет в Нью-Йорк, США и получил свою вирусную программу выключения и был взломан хакером в Польша. Когда хакер получил доступ токен и токен обновления, он пытается олицетворять пользователя и использовать наш сервис. Но после того, как токен короткого доступа истекает, когда хакер пытается обновить токен доступа, мы, на сервере, заметили резкое изменение IP-адреса в истории поведения пользователей (Эй, этот парень входит в систему в США и теперь обновляет доступ в Польше после всего 3600???). Мы завершаем процесс обновления, аннулируем сам токен обновления и снова запрашиваем ввод имени пользователя/пароля.

3. пользователь это вредоносного пользователей. Он предназначен для злоупотребления нашим сервисом, вызывая 1000 раз наш API каждую минуту с помощью робота. Он вполне может делать это до 3600 секунд спустя, когда он пытается обновить маркер доступа, мы заметили его поведение и подумали, что он, возможно, не человек. Мы отклоняем и завершаем процесс обновления и просим его снова ввести имя пользователя/пароль. Это может нарушить автоматический поток его робота. По крайней мере, ему неудобно.

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

другое слово, вы также можете попытаться ограничить контроль ущерба от украденного токена / злоупотребления сервисом, реализуя на каждом вызове api базовую IP watch dog или любые другие меры. Но это дорого, как вы придется читать и записывать запись о пользователе и замедлит ваш ответ сервера.

ни один из этих ответов не попадает в основную причину существования токенов обновления. Очевидно, вы всегда можете получить новую пару access-token/refresh-token, отправив свои учетные данные клиента на сервер аутентификации-вот как вы их получаете в первую очередь.

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

этот ответ от Джастина Ричера через стандартный список электронной почты OAuth 2. Это Опубликовано с его разрешения.

время жизни токена обновления зависит от сервера авторизации (AS) - они могут истечь, быть отозваны и т. д. Разница между токеном обновления и токеном доступа заключается в аудитории: токен обновления возвращается только на сервер авторизации, а токен доступа-на сервер ресурсов (RS).

кроме того, просто получить маркер доступа не значит, что пользователь вошел в систему. Фактически, пользователь может даже больше не быть там, что на самом деле является предполагаемым вариантом использования токена обновления. Обновление маркера доступа даст вам доступ к API от имени пользователя,он не скажет вам, есть ли пользователь.

OpenID Connect не просто дает вам информацию о пользователе из маркера доступа, он также дает вам маркер ID. Это отдельная часть данных, которая направлена на самого клиента, а не на AS или RS. В OIDC, вы должны рассматривать только кого-то фактически "вошедшего" по протоколу, если вы можете получить новый токен ID. Освежающий это не может быть достаточно.

для получения дополнительной информации, пожалуйста, прочитайте http://oauth.net/articles/authentication/

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

на клиент Это приложение / веб-сайт / программа/..., при поддержке сервера, который хочет аутентифицировать a пользователей используя стороннюю службу аутентификации. Секрет клиента-это (случайная) строка, известная как этому клиенту, так и аутентификации сервер. Используя этот секрет клиент может идентифицировать себя с сервером аутентификации, получив авторизация запрос маркера доступа.

чтобы получить маркер начального доступа и токен обновления, необходимо:

• пользователь ID
• пароль пользователя
• идентификатор клиента
• секрет клиента

чтобы получить обновленный токен доступа, однако клиент использует следующая информация:

• идентификатор клиента
• секрет клиента
• обновить маркер

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

Это также показывает, что потеря маркера обновления не является проблемой, потому что идентификатор клиента и секрет не известны. Он также показывает, что сохранение идентификатора клиента и секрет клиента является vital.

клиенты могут быть скомпрометированы многими способами. Например, мобильный телефон можно клонировать. Истечение срока действия маркера доступа означает, что клиент вынужден повторно пройти аутентификацию на сервере авторизации. Во время повторной аутентификации сервер авторизации может проверить другие характеристики (IOW выполняет адаптивное управление доступом).

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

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

чтобы еще больше упростить ответ B T: используйте токены обновления, когда вы обычно не хотите, чтобы пользователь снова вводил учетные данные, но все же хотите, чтобы власть могла отменить разрешения (путем отмены токена обновления)

нельзя отменить маркер доступа, только маркер обновления.

почему бы просто не сделать способом так долго, как маркер обновления и не иметь маркер обновления?

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

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

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

во-первых, клиент аутентифицируется с сервером авторизации, предоставляя разрешение на авторизацию.

затем клиент запрашивает сервер ресурсов для защищенного ресурса, предоставляя маркер доступа.

сервер ресурсов проверяет маркер доступа и предоставляет защищенный ресурс.

клиент делает защищенный запрос ресурса к серверу ресурсов, предоставляя маркер доступа, где сервер ресурсов проверяет его и выполняет запрос, если он действителен. Этот шаг повторяется до тех пор, пока не истечет срок действия маркера доступа.

если срок действия маркера доступа истекает, клиент аутентифицируется на сервере авторизации и запрашивает новый маркер доступа, предоставляя маркер обновления. Если маркер доступа недопустим, сервер ресурсов отправляет клиенту ответ об ошибке недопустимого маркера.

клиент аутентифицируется с сервером авторизации, предоставляя обновление знак.

сервер авторизации проверяет обновления токена аутентификации клиента и выдает новый маркер доступа, если он действителен.

Предположим, вы делаете access_token длиться очень долго, и не имеют refresh_token, так что в один день, хакер получить этот access_token и он может получить доступ ко всем защищенным ресурсам!

но если у вас есть refresh_token, время работы access_token короткое, поэтому хакеру трудно взломать ваш access_token, потому что он будет недействительным через короткий промежуток времени. Access_token может быть восстановлен только с помощью не только refresh_token, но и client_id и client_secret, который хакер нет.

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

мы можем использовать токены доступа и обновления для этой цели. Когда API вызывается с помощью маркера доступа, сервер ресурсов проверяет кэш на наличие прав доступа. Если есть какие-либо новые гранты доступа, это не отражается сразу. Как только токен доступа истечет (скажем, через 30 минут), и клиент использует токен обновления для создания нового токена доступа, кэш может быть обновлен обновленной информацией о праве доступа пользователя из БД.

другими словами, мы можем переместить дорогостоящие операции из каждого вызова API с помощью маркеров доступа к событию генерации маркеров доступа с помощью обновления знак.

в то время как токен обновления сохраняется сервером авторизации. Маркер доступа является автономным, поэтому сервер ресурсов может проверить его без сохранения, что экономит усилия по извлечению в случае проверки. Еще один момент отсутствует в обсуждении из rfc6749#page-55

"например, сервер авторизации может использовать маркер обновления вращение, при котором новый токен обновления выдается с каждым доступом маркер ответа "обновить".Предыдущий маркер признана недействительной, но сохраняется сервером авторизации. Если токен обновления скомпрометирован и впоследствии использован как злоумышленником, так и законный клиент, один из них представит недействительное обновление знак, который будет информировать сервер авторизации нарушения."

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