В этой статье анализируется процесс взаимодействия и точки безопасности токенов доступа и токенов обновления, а также рассматриваются методы и принципы правильного управления и использования токенов доступа и токенов обновления.
Основной процесс использования токена в Oauth2
Давайте сначала посмотрим на один изRFC6749Основной процесс использования токена в Oauth2 определен, вы, вероятно, можете понять использование токена доступа и токена обновления.
+--------+ +---------------+
| |--(A)------- Authorization Grant --------->| |
| | | |
| |<-(B)----------- Access Token -------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)---- Access Token ---->| | | |
| | | | | |
| |<-(D)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server |
| |--(E)---- Access Token ---->| | | |
| | | | | |
| |<-(F)- Invalid Token Error -| | | |
| | +----------+ | |
| | | |
| |--(G)----------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token -------------| |
+--------+ & Optional Refresh Token +---------------+
Figure 2: Refreshing an Expired Access Token
Сервер авторизации на приведенном выше рисунке транслируется в службу авторизации, которая отвечает за выдачу токенов. Сервер ресурсов транслируется в службы ресурсов, то есть ресурсы, к которым разрешен доступ, например API-интерфейсы. В распределенных приложениях они должны принадлежать разным сервисам. Стоит отметить, что сервер ресурсов не выдает Токенов, но может самостоятельно проверить Токен доступа.
Приведенная выше блок-схема включает следующие шаги.
- (A) Клиент запрашивает токен доступа с сервера авторизации (весь процесс аутентификации и авторизации может быть завершен несколькими запросами)
- (B) Сервер авторизации проверяет правильность идентификации клиента и разумность запрошенных ресурсов, а затем выдает токен доступа и токен обновления и может одновременно возвращать дополнительные атрибуты, такие как время истечения срока действия токена доступа.
- (C) Запрос ресурсов с токеном доступа
- (D) Сервер ресурсов возвращает запрошенный контент после проверки правильности токена доступа.
- (E) Уведомление:Описанные выше шаги (C) (D) можно повторять до тех пор, пока не истечет срок действия маркера доступа. Если клиент может определить, что срок действия маркера доступа истек или скоро истечет до запроса (выданное время истечения срока действия), он может сразу перейти к шагу (G). В противном случае он будет запрошен снова, и произойдет этот шаг.
- (F) Если токен доступа недействителен, сервер ресурсов откажется отвечать на ресурс и вернет ошибку недопустимого токена.
- (G) Клиент повторно запрашивает токен доступа с сервера авторизации, но на этот раз ему нужно только принести токен обновления, и пользователю не нужно снова выполнять процесс аутентификации и авторизации. Таким образом, пользователь может быть равнодушен.
- (H) Сервер авторизации проверяет токен обновления и, если он действителен, выдает новый токен доступа (или одновременно выдает новый токен обновления).
Подытожим несколько моментов.Токен доступа является наиболее часто используемым удостоверением для запроса ресурсов, но срок его действия относительно короткий.Токен обновления имеет более длительный срок действия и будет отправлен на сервер авторизации только для получения нового токена доступа.
Итак, возникает вопрос:
Как служба ресурсов проверяет токен доступа без службы авторизации?
Возьмите JTW в качестве примера. Если маркер доступа выдан в форме JWT, служба ресурсов может использовать метод проверки подписи, чтобы определить, является ли она законной.Ей нужно только синхронизировать копию ключа подписи в службе ресурсов. Некоторые также используют асимметричное шифрование, служба авторизации использует закрытый ключ для выдачи, а служба ресурсов использует открытый ключ для проверки. Поскольку JWT разрешено нести некоторую информацию, пользователей, разрешения, срок действия и т. д., после того как служба ресурсов решит, что JWT является законным, она может продолжить судить о том, можно ли получить доступ к ресурсу в соответствии с переданной информацией. Вот и все, преимущество этого в том, что действительность можно быстро проверить, недостаток в том, что после того, как токен доступа будет выпущен, его будет сложно восстановить, и он может быть признан недействительным только по истечении срока действия.
Как механизм Refresh Token повышает безопасность?
Одной из целей токена обновления является сохранение пользователя в системе в течение более длительного периода времени, поэтому можно напрямую увеличить срок действия токена доступа, что может сэкономить много бесполезных шагов. Ответ небезопасен, и причина относится к ответу на вопрос выше.
Например, пользователь успешно входит в систему и получает токен доступа, который может публиковать.В это время администратор обнаруживает, что он опубликовал спам и отозвал разрешение на публикацию, и эта информация обычно принадлежит управлению службой авторизации, то есть скажем, он авторизует в следующий раз.Сервисный запрос Access Token не получит разрешение на публикацию. Но если Access Token, полученный пользователем, действителен в течение длительного времени, то пользователь может размещать сообщения в течение длительного времени. Если срок действия токена доступа истекает в течение короткого периода времени, он должен повторно авторизовать запрос на обслуживание, и служба авторизации не будет выдавать токен доступа с разрешением на публикацию.
Во втором примере, если токен доступа имеет более длительный срок действия, после кражи злоумышленник может использовать токен доступа в течение длительного времени. Если вы сообразительны, вы можете подумать, что злоумышленник может одновременно украсть Refresh Token.
RFC6749Как описано в Разделе 10, Авторизованные службыОтношения привязки между Refresh Token и клиентом должны поддерживаться., то есть только клиент легитимных пользователей (о чем можно судить по IP, UA и другим данным) может запросить через. Сделав шаг назад, если злоумышленник имитирует, что клиент может выполнить запрос на обновление, то это зависит от того, кто обновляет первым. Как авторизованный сервисОбновить токен можно установить действительным один раз, поэтому независимо от того, какой из них обновится первым, другой сообщит об ошибке. Если пользователь обновляется первым, злоумышленник завершает игру с двойной недействительностью токена доступа и токена обновления. Если злоумышленник сначала обновится, законный пользователь получит сообщение об ошибке, и служба авторизации предложит пользователю перезапустить аутентификацию с шага (A) на приведенном выше рисунке, чтобы вернуть действительный токен обновления законному пользователю. .
Суммировать
Токен доступа должен поддерживаться с коротким периодом действия. Слишком длинный небезопасен, а слишком короткий также повлияет на взаимодействие с пользователем, поскольку частые обновления будут приводить к ненужным сетевым запросам. Вы можете сослаться на тот факт, что мы часто отключаемся после того, как некоторые веб-сайты перестают работать в течение определенного периода времени, это время является сроком действия Refresh Token, и Access Token не должен превышать это время.
Срок действия Refresh Token определяется тем, как долго пользователю не нужно снова входить в систему, что может быть очень долгим, в зависимости от бизнеса. Когда мы используем некоторые приложения, даже если мы не открывали их в течение месяца, мы все равно вошли в систему. Это то, что решает Refresh Token. Когда служба авторизации получает Refresh Token, ей необходимо дополнительно проверить клиента, чтобы максимально исключить кражу.
Все токены должны храниться в приватном месте, то есть им может пользоваться только клиент, и все токены должны храниться в приватном месте.TLSОтправить по каналу (например, HTTPS).