#oauth #jwt #access-token #jwt-auth #refresh-token
#oauth #токен доступа #jwt #обновить токен
Вопрос:
Я следую этой статье, чтобы понять токены refesh.
В моем случае мне нужно подключиться к REST api, используя grant_type=password, и я получаю токен с 5-минутным сроком службы. Поэтому каждые 5 минут я должен отправлять POST-запрос, передавая идентификатор клиента, имя пользователя и пароль, чтобы получить новый токен доступа.
Другим вариантом было бы опубликовать сообщение с grant_type=refresh_token, без необходимости отправлять имя пользователя и пароль. В моем случае я использую api, поэтому передача учетных данных не требует каких-либо действий от конечного пользователя. Для меня это просто дополнительные параметры для отправки в запросе POST.
В обоих случаях я должен выпускать новое сообщение каждые 5 минут.
Это единственное преимущество (не требующее повторной передачи учетных данных) использования токена reresh или есть что-то еще, чего мне не хватает?
Ответ №1:
Справочная информация
Предоставление пароля OAuth 2.0
Тип предоставления пароля — это способ обмена учетных данных пользователя на токен доступа. Поскольку клиентское приложение должно собирать пароль пользователя и отправлять его на сервер авторизации, не рекомендуется вообще больше использовать это разрешение.
Тип предоставления токена обновления используется клиентами для обмена токена обновления на токен доступа, когда срок действия токена доступа истек.
Это позволяет клиентам продолжать иметь действительный токен доступа без дальнейшего взаимодействия с пользователем.
Подумайте об этом.
Допустим, я добавляю свой логин и пароль для своей учетной записи Twitter в ваше приложение, а затем вы используете это для запроса доступа из Twitter к учетной записи may для публикации. Три месяца спустя я забыл, что настроил ваше потрясающее приложение на выполнение чего-либо в моей учетной записи Twitter, и я меняю свой пароль. Ваша система сломается.
Теперь, допустим, я использовал Oauth2, чтобы предоставить вам доступ к моей учетной записи Google Drive, теперь ваше потрясающее приложение может делать все, что ему нужно, в моей учетной записи диска. Теперь, спустя три месяца, я снова забыл, что предоставил доступ к вашему потрясающему приложению, у меня есть память о золотой рыбке, которую вы видите. Я меняю свой пароль. Ничего не происходит, ваше потрясающее приложение по-прежнему имеет доступ.
Теперь подумайте об этом, с помощью oauth2 я могу предоставить вам доступ только к чтению из моей учетной записи Google Drive, а не обновлять ее (область действия). Это и система знают, что на самом деле я не выполняю действия.
При входе в систему клиента (логин и пароль) большую часть времени системе кажется, что это фактический владелец учетной записи, делающий запросы. Вы также можете не ограничивать доступ с помощью входа в систему клиента, поскольку по большей части у вас есть полный доступ.
примечание
да, я игнорирую ту часть, в которой оба возвращаемых токена являются временем истечения срока действия. Это потому, что для всех интенсивных целей они одинаковы, но это сильно зависит от того, как настроен используемый вами сервер аутентификации. Они могут быть настроены так, чтобы быть действительными только в течение часа или дня. Они могут предоставлять вам разные области доступа, опять же, это сильно отличается от сервера аутентификации к серверу аутентификации.