Раздел 4.2 проекта протокола OAuth 2.0 указывает, что сервер авторизации может возвращать как access_token(который используется для аутентификации себя с помощью ресурса), так и a refresh_token, который используется исключительно для создания нового access_token:
https://tools.ietf.org/html/rfc6749#section-4.2
Почему есть оба? Почему бы просто не сделать access_tokenпоследний до тех пор, пока refresh_tokenи не иметь refresh_token?
Ответы:
Идея обновления токенов заключается в том, что если токен доступа скомпрометирован, поскольку он недолговечен, у злоумышленника есть ограниченное окно, в котором его можно использовать.
Токены обновления, если они скомпрометированы, бесполезны, поскольку злоумышленнику требуется идентификатор клиента и секрет в дополнение к токену обновления, чтобы получить токен доступа.
Сказав это , поскольку каждый вызов как сервера авторизации, так и сервера ресурсов выполняется по SSL - включая исходный идентификатор клиента и секрет, когда они запрашивают токены доступа / обновления - я не уверен относительно того, как токен доступа больше " компромисс », чем долгоживущая комбинация обновления и клиент / секретная комбинация.
Это, конечно, отличается от реализаций, где вы не контролируете серверы авторизации и ресурсов.
Вот хорошая тема, рассказывающая об использовании токенов обновления: OAuth Archives .
Цитата из вышесказанного, рассказывающая о целях безопасности токена обновления:
Обновить токены ... снижает риск долгой утечки access_token (параметр запроса в файле журнала на небезопасном сервере ресурсов, бета-версия или плохо закодированное приложение сервера ресурсов, клиент JS SDK на не https-сайте, который помещает access_token в печенье и т. д.)
Ссылка на обсуждение, предоставленная Catchdave, имеет еще одно действительное замечание (оригинал, мертвая ссылка), сделанное Диком Хардтом, которое, я считаю, стоит упомянуть здесь в дополнение к тому, что было написано выше:
Мое воспоминание о фишках обновления было для безопасности и аннулирования. <...>
аннулирование: если токен доступа самодостаточен, авторизацию можно отозвать, не выдавая новые токены доступа. Ресурсу не нужно запрашивать сервер авторизации, чтобы узнать, является ли токен доступа действительным. Это упрощает проверку токена доступа и упрощает масштабирование и поддержку нескольких серверов авторизации. Существует окно времени, когда токен доступа действителен, но авторизация отменена.
Действительно, в ситуации, когда сервер ресурсов и сервер авторизации являются одним и тем же объектом, и когда соединение между пользователем и любым из них (как правило) одинаково безопасно, нет особого смысла хранить токен обновления отдельно от токена доступа.
Хотя, как упоминалось в цитате, еще одна роль токенов обновления заключается в том, чтобы гарантировать, что токен доступа может быть отозван пользователем в любое время (например, через веб-интерфейс в его профилях), при этом сохраняя масштабируемость системы в то же время. ,
Как правило, токены могут быть случайными идентификаторами, указывающими на конкретную запись в базе данных Сервера, или они могут содержать всю информацию в себе (безусловно, эта информация должна быть подписана, например , 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-сторож или любые другие меры. Но это дорого, так как вы должны читать и записывать записи о пользователе и замедлять реакцию вашего сервера.
Ни один из этих ответов не доходит до основной причины, по которой существуют токены обновления. Очевидно, что вы всегда можете получить новую пару access-token / refresh-token, отправив свои учетные данные клиента на сервер аутентификации - так вы и получите их в первую очередь.
Таким образом, единственная цель токена обновления состоит в том, чтобы ограничить использование учетных данных клиента, передаваемых по проводам в службу аутентификации. Чем короче срок действия маркера доступа, тем чаще придется использовать учетные данные клиента для получения нового токена доступа, и, следовательно, больше возможностей злоумышленникам скомпрометировать учетные данные клиента (хотя это может быть очень сложно в любом случае, если для их отправки используется асимметричное шифрование). Поэтому, если у вас есть одноразовый токен обновления, вы можете сделать так, чтобы ttl маркеров доступа был произвольно мал, не ставя под угрозу учетные данные клиента.
Чтобы устранить некоторую путаницу, вы должны понимать роли клиентского секрета и пароля пользователя , которые сильно различаются.
Клиент представляет собой приложение / сайт / программа / ..., при поддержке сервера, который хочет аутентифицировать на пользователя с помощью службы аутентификации третьей стороной. Секрет клиента - это (случайная) строка, известная как этому клиенту, так и серверу аутентификации. Используя этот секрет, клиент может идентифицировать себя с сервером аутентификации, получая авторизацию для запроса токенов доступа.
Чтобы получить начальный токен доступа и обновить токен, необходимо:
Однако для получения обновленного токена доступа клиент использует следующую информацию:
Это ясно показывает разницу: при обновлении клиент получает авторизацию для обновления токенов доступа, используя свой секретный ключ клиента, и, таким образом, может повторно аутентифицировать пользователя, используя токен обновления вместо идентификатора пользователя + пароль. Это эффективно предотвращает необходимость повторного ввода пароля пользователем.
Это также показывает, что потеря маркера обновления не является проблемой, поскольку идентификатор клиента и секрет неизвестны. Это также показывает, что сохранение идентификатора клиента и его тайны крайне важно .
Этот ответ от Джастина Ричера через стандартный список рассылки OAuth 2. Это опубликовано с его разрешения.
Срок действия токена обновления зависит от сервера авторизации (AS) - он может истечь, быть аннулирован и т. Д. Разница между токеном обновления и токеном доступа заключается в аудитории: токен обновления возвращается только на сервер авторизации, токен доступа отправляется на сервер ресурсов (RS).
Кроме того, просто получение токена доступа не означает, что пользователь вошел в систему. На самом деле, пользователь может даже не быть там, что фактически является предполагаемым вариантом использования токена обновления. Обновление токена доступа даст вам доступ к API от имени пользователя, но не скажет, есть ли там пользователь.
OpenID Connect не только предоставляет вам информацию о пользователях из токена доступа, но и дает идентификационный токен. Это отдельный фрагмент данных, который направлен на самого клиента, а не на AS или RS. В OIDC вы должны рассматривать кого-то, кто действительно «вошел» по протоколу, только если вы можете получить новый идентификационный токен. Освежить его вряд ли будет достаточно.
Для получения дополнительной информации, пожалуйста, прочитайте http://oauth.net/articles/authentication/
Клиенты могут быть скомпрометированы разными способами. Например, мобильный телефон может быть клонирован. Истечение срока действия маркера доступа означает, что клиент вынужден повторно пройти аутентификацию на сервере авторизации. Во время повторной аутентификации сервер авторизации может проверять другие характеристики (IOW выполняет адаптивное управление доступом).
Маркеры обновления допускают только повторную аутентификацию клиента, при которой повторная авторизация вызывает диалог с пользователем, который многие указали, что он предпочел бы не делать этого.
Токены обновления в основном размещаются в том же месте, где обычные веб-сайты могут периодически проводить повторную аутентификацию пользователей через час или около того (например, банковский сайт). В настоящее время он не используется широко, так как большинство социальных веб-сайтов не проходят повторную проверку подлинности пользователей, так зачем им выполнять повторную проверку подлинности клиента?
Почему бы просто не сделать access_token последним, пока refresh_token, и не иметь refresh_token?
В дополнение к отличным ответам, предоставленным другими людьми, существует еще одна причина, по которой следует использовать токены обновления, связанные с утверждениями.
Каждый токен содержит утверждения, которые могут включать в себя все, что угодно от имени пользователя, его роли или поставщика, который создал требование. По мере обновления токена эти претензии обновляются.
Если мы обновляем токены чаще, мы, очевидно, увеличиваем нагрузку на наши службы идентификации, однако получаем более точные и актуальные требования.
Чтобы еще больше упростить ответ BT: используйте маркеры обновления, если вы обычно не хотите, чтобы пользователь снова вводил учетные данные, но при этом хотите, чтобы у вас была возможность отозвать разрешения (путем отзыва маркера обновления)
Вы не можете отозвать токен доступа, только токен обновления.
Этот ответ был составлен с помощью двух старших разработчиков (Джон Брайтон и Дэвид Дженнес).
Основной причиной использования токена обновления является уменьшение поверхности атаки.
Давайте предположим, что нет ключа обновления, и давайте рассмотрим этот пример:
Здание имеет 80 дверей. Все двери открываются одним и тем же ключом. Ключ меняется каждые 30 минут. По истечении 30 минут я должен дать старый ключ создателю ключа и получить новый ключ.
Если я хакер и получу ваш ключ, то по истечении 30 минут я отправлю его курьеристу и получу новый ключ. Я смогу постоянно открывать все двери независимо от смены ключа.
Вопрос: Сколько хакерских возможностей у меня было за 30 минут против ключа? У меня было 80 возможностей взлома, каждый раз, когда вы использовали ключ (представьте, что вы делаете сетевой запрос и передаете токен доступа для идентификации себя). Так что это 80X поверхность атаки.
Теперь давайте рассмотрим тот же пример, но на этот раз давайте предположим, что есть ключ обновления.
Здание имеет 80 дверей. Все двери открываются одним и тем же ключом. Ключ меняется каждые 30 минут. Чтобы получить новый ключ, я не могу передать старый токен доступа. Я должен только передать ключ обновления.
Если я хакер и получу ваш ключ, я могу использовать его в течение 30 минут, но по истечении 30 минут отправка его создателю ключей не имеет значения. Если я это сделаю, то создатель ключей просто скажет этот жетон плохого обновления. Чтобы иметь возможность продлить свой хак, мне пришлось бы взломать курьера для создателя ключей. У курьера есть особый ключ (думайте об этом как символ обновления).
Вопрос: Сколько хакерских возможностей у меня было за 30 минут против ключа обновления? 80? У меня была только 1 возможность взлома. В течение времени курьер общается с создателем ключей. Так что это 1X поверхность атаки. У меня было 80 возможностей взлома против ключа, но они не годятся после 30 минут.
Сервер будет проверять токен доступа на основе учетных данных и подписи (обычно) JWT.
Утечка токена доступа - это плохо, но как только он истекает, он больше не нужен злоумышленнику. Утечка токена обновления гораздо хуже, но, вероятно, менее вероятна. (Я думаю, что есть вопрос, является ли вероятность утечки токена обновления намного ниже, чем утечка токена доступа, но это идея.)
Дело в том, что токен доступа добавляется к каждому вашему запросу, тогда как токен обновления используется только во время процесса обновления. Поэтому меньше шансов MITM увидеть токен
Частота помогает злоумышленнику. Подобные сердцу потенциальные уязвимости в SSL, потенциальные уязвимости в клиенте и потенциальные уязвимости в сервере делают возможной утечку.
Кроме того, если сервер авторизации отделен от сервера приложений, обрабатывающего другие клиентские запросы, этот сервер приложений никогда не увидит токены обновления. Он будет видеть только токены доступа, которые не будут жить намного дольше.
Отделение хорошо для безопасности.
Не в последнюю очередь увидеть этот удивительный ответ
О каком токене обновления не идет речь?
Возможность обновлять / отзывать уровень доступа с помощью токенов обновления является побочным продуктом выбора использования токенов обновления, в противном случае автономный токен доступа может быть отозван или его уровень доступа изменен по истечении срока действия, и пользователи получают новый токен.
Предположим, вы делаете access_tokenпоследнее очень долго, и не имеете refresh_token, так что в один день хакер получит это, access_tokenи он сможет получить доступ ко всем защищенным ресурсам!
Но если у вас есть refresh_token, время access_tokenжизни короткое, поэтому хакеру сложно взломать ваш, access_tokenпотому что он будет недействительным через короткий промежуток времени.
Access_tokenможет быть восстановлен только с помощью не только, refresh_tokenно и с помощью client_idи client_secret, который хакер не имеет.
Пока токен обновления сохраняется сервером авторизации. Токен доступа самодостаточен, поэтому сервер ресурсов может проверить его, не сохраняя, что экономит усилия поиска в случае проверки. Еще один момент, отсутствующий в обсуждении - это rfc6749 # page-55
«Например, сервер авторизации может использовать ротацию токенов обновления, при которой новый токен обновления выдается с каждым ответом обновления токена доступа. Предыдущий токен обновления недействителен, но сохраняется сервером авторизации. Если токен обновления скомпрометирован и впоследствии используется и злоумышленник, и законный клиент, один из них представит недействительный токен обновления, который сообщит серверу авторизации о нарушении ».
Я думаю, что весь смысл использования токена обновления заключается в том, что даже если злоумышленнику каким-то образом удастся получить токен обновления, идентификатор клиента и секретную комбинацию. При последующих вызовах для получения нового токена доступа от злоумышленника можно отслеживать, если каждый запрос на обновление приводит к появлению нового токена доступа и токена обновления.
A Single-Page Application (normally implementing Single-Page Login Flow) should not under any circumstances get a Refresh Token. The reason for that is the sensitivity of this piece of information. You can think of it as user credentials, since a Refresh Token allows a user to remain authenticated essentially forever. Therefore you cannot have this information in a browser, it must be stored securely.
Давайте рассмотрим систему, в которой каждый пользователь связан с одной или несколькими ролями, а каждая роль связана с одной или несколькими привилегиями доступа. Эта информация может быть кэширована для лучшей производительности API. Но тогда могут быть изменения в конфигурации пользователя и роли (например, может быть предоставлен новый доступ или текущий доступ может быть отменен), и они должны быть отражены в кеше.
Мы можем использовать доступ и обновлять токены для этой цели. Когда API вызывается с токеном доступа, сервер ресурсов проверяет кэш на наличие прав доступа. Если есть какие-либо новые права доступа, это не отражается сразу. Когда срок действия маркера доступа истекает (скажем, через 30 минут), и клиент использует токен обновления для создания нового токена доступа, кэш можно обновить, обновив информацию о правах доступа пользователя из БД.
Другими словами, мы можем перемещать дорогостоящие операции из каждого вызова API, используя токены доступа, в событие генерации маркеров доступа, используя токен обновления.
Сначала клиент аутентифицируется на сервере авторизации, предоставляя разрешение на авторизацию.
Затем клиент запрашивает у сервера ресурсов защищенный ресурс, предоставляя маркер доступа.
Сервер ресурсов проверяет токен доступа и предоставляет защищенный ресурс.
Клиент отправляет защищенный запрос ресурса на сервер ресурсов, предоставляя маркер доступа, где сервер ресурсов проверяет его и обслуживает запрос, если он действителен. Этот шаг повторяется до истечения срока действия токена доступа.
Если срок действия маркера доступа истекает, клиент аутентифицируется на сервере авторизации и запрашивает новый токен доступа, предоставляя токен обновления. Если токен доступа недействителен, сервер ресурсов отправляет клиенту неверный ответ об ошибке токена.
Клиент аутентифицируется на сервере авторизации, предоставляя маркер обновления.
Затем сервер авторизации проверяет токен обновления путем аутентификации клиента и выдает новый токен доступа, если он действителен.
access token + refresh token?