Android App Session + JWT в API хорошей практики?

Question

Я делаю Android приложение и API для него. Я хочу, чтобы пользователь входил в приложение до тех пор, пока оно не выйдет или не переустановит приложение и т. Д. c. Но я также хочу защитить API с JWT, срок действия которого истечет, скажем, через час.

Моя идея состояла в том, чтобы сохранить имя пользователя в хранилище приложения после успешного входа в систему и последний JWT. Затем, когда приложение открыто, оно будет взаимодействовать с API, и даже если срок действия JWT истек, но он «действителен», он снова выдаст новый токен. Но это безопасное решение? Или есть лучшее решение для этого?

Answer 1

Это классический случай использования токенов refre sh. Способ работы потока:

• Пользователь входит в систему, сервер создает недолговечный (~ 1 час) JWT и долгоживущий токен refre sh и отправляет их в интерфейс.

• Интерфейс отправляет JWT для каждого вызова API, пока он еще действителен

• В случае истечения срока действия JWT Затем внешний интерфейс должен использовать токен refre sh для получения нового JWT AND и нового токена refre sh (вращающийся токен refre sh - см. https://tools.ietf.org/html/rfc6749#section -10.4 ).

• Если срок действия маркера refre sh истекает, пользователь должен снова войти в систему.

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

Зачем нам нужен токен refre sh (в отличие от использования недействительного JWT для получения нового)?

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

• Если злоумышленник завладеет JWT после истечения срока его действия, он не может продолжать его использовать.

Что если злоумышленник украдет жетон refre sh?

Именно здесь в игру вступает очарование вращающихся жетонов refre sh. Когда вы меняете токен refre sh при каждом использовании (и отзываете старый), это позволяет вам: 1) значительно минимизировать риск кражи 2) обнаружить, что кража произошла! И как только вы обнаружите это, вы можете go отозвать весь сеанс, чтобы обеспечить безопасность этого пользователя.

Это и другие преимущества подробно описаны в этом сообщении в блоге

Примечание о путанице в ссылках * refre sh в других обсуждениях

Во многих местах указывается, что вы не должны отправлять токен refre sh на внешний интерфейс. Это верно в случае потока OAuth - когда третья сторона выдает токены для использования вашей системой. В этом случае «внешний интерфейс» - это ваша система (внешний интерфейс и бэкэнд вашего приложения), а «внутренний интерфейс» - это третья сторона. Я понимаю, что это может немного сбивать с толку, но я рад поговорить об этом здесь (моя ручка @rp)

Заключительная нота

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

Надеюсь, это поможет!

Answer 2

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

Refre sh токены содержат информацию, необходимую для получения нового токена доступа. Другими словами, всякий раз, когда токен доступа требуется для доступа к указанному ресурсу c, клиент может использовать токен refre sh для получения нового токена доступа, выпущенного сервером аутентификации. - Себастьян Пейротт

Вам нужно только правильно проверить утверждение токена, и тогда вы будете готовы прочитать токен refre sh, имя пользователя и любую другую информацию. .

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