Предоставление разрешения Oauth2: Почему нет токена обновления?

Я ищу Oauth2, чтобы позволить разработчикам разрешать пользователям своего приложения использовать мой сервис. Я нашел несколько источников, которые говорят, что мой сервер авторизации должен вернуть токен доступа, когда пользователь отправляет утверждение (JWT в моем случае), но он не должен возвращать токен обновления. Мне интересно, каков вред в возврате токена обновления. Разработчики могут сделать недействительными токены обновления/доступа, вызвав Api, что делает недействительным любой доступ, предоставляемый с определенного идентификатора JWT.Предоставление разрешения Oauth2: Почему нет токена обновления?

источник

2017-02-22 Mustack

С помощью [RFC7521] (https://tools.ietf.org/html/rfc7521) токены обновления бесполезны, как указано в [разделе 4.1] (https://tools.ietf.org/html /rfc7521#section-4.1): * Клиенты могут обновить токен с истекшим доступом, запросив новый, используя то же утверждение, если оно все еще действительное, или с новым утверждением. * –

Я не согласен, что это бесполезно. Я думаю о клиенте, который просыпается после того, как некоторое время неактивно. Этот клиент должен будет спросить свой сервер приложений для JWT, а затем обменять этот JWT на токен доступа. Это 2 раунда поездки против 1 тура. Возможно, это не большое дело, но здесь есть незначительная производительность. – Mustack

Это бесполезно, потому что клиент может обновить его либо путем отправки того же утверждения (если не истек), либо создания нового. Так как он обычно генерируется на стороне клиента, то это 1 раунд. –

Эта рекомендация неверна. Обновить токены являются необязательными и могут быть выпущены по усмотрению сервера авторизации после того, как клиент предоставит разрешение на авторизацию. См Oauth2 specification

1,5 Обновить лексемы

Обновить лексемы учетные данные, используемые для получения маркера доступа. Обновление токенов предоставляется клиенту сервером авторизации и используется для получения нового токена доступа, когда токен доступа становится недействительным или истекает, или для получения токенов доступа с одинаковой или более узкой областью (маркеры доступа могут иметь более короткий срок службы и меньшее количество разрешений, чем разрешено владельцем ресурса ). Выдача токена обновления необязательна по усмотрению сервера авторизации . Если сервер авторизации выдает токен обновления , он включается при выдаче маркера доступа (т. Е. Шаг (D) в Рисунок 1).

источник

2017-02-22 20:04:07 pedrofb

Спасибо, что указали это. Я перепроверял источник, который я прочитал, и заставил меня подвергнуть сомнению это. Оказывается, это скорее наблюдение, чем рекомендация. В нем говорится, что вы обычно не даете токен обновления в потоке предоставления утверждений. Наверное, мне просто интересно, не хватает ли здесь недостатка. https://tools.ietf.org/html/rfc7521 – Mustack

Может быть, речь идет о различных потоках разрешения авторизации в Oauth2.0, чтобы получить токен доступа. «Предоставление кода авторизации» предоставляет код авторизации, где на втором этапе вы можете получить токен доступа/обновления. Поток «Неявный грант» обеспечивает токен доступа за один шаг и не позволяет использовать токены обновления – pedrofb

Предоставление разрешения Oauth2: Почему нет токена обновления?

ответ

Смежные вопросы