Задать вопрос

SPA и REST API — как грамотно построить аутентификацию?

Сейчас делаю REST API, которое будет использоваться в SPA и мобильных приложениях.
Теорию про разные методы аутентификации вроде знаю, прочитал много статей, примеры просмотрел но пока не понимаю, как сделать удобно и безопасно.
С одной стороны, вроде, очевидно: token-based authentication – OAuth или что-то вроде того. Можно с JWT поэкспериментировать. Но токен можно стащить, поэтому он должен быть с ограниченным временем жизни.
С другой стороны, если пользователь два дня не заходил в приложение, и его токен протух, то его не должно выкидывать из приложения. Для пользователя должно быть всё максимально удобно.
Вроде есть такая штука, как refresh token, но как его правильно применять?
Есть ли смысл в полностью stateless API, или удобнее хранить сессии?

Буду очень признателен за статьи, где подробно описаны данные проблемы и способы их решения, best practices в данной области, или, может, готовые инструменты какие...
  • Вопрос задан
  • 9601 просмотр
Подписаться 35 Средний Комментировать
Пригласить эксперта
Ответы на вопрос 7
liveunit
@liveunit
Думаю jwt аутентефикации хватит с головой.
Вот тут написано хорошо обо всех токенах и как они работают.
https://auth0.com/blog/refresh-tokens-what-are-the...
Ответ написан
@motomac
Делаем два метода аутентификации: Resource Owner Password Credentials Grant и Refresh token grant.

SPA отправляет логин/пароль юзера на первый endpoint. В ответ получаем access_token (например, JWT), refresh_token и expires_in. Сохраняем все это добро куда-нибудь, например, в Local Storage. Время жизни JWT-токена лучше ставить небольшое (например, 1 час), потому что отозвать его нельзя. Далее SPA при каждом запросе к API проверяет время жизни токена expires_in из Local Storage, и когда оно истекает, отправляет запрос на обновление токена (refresh_token). Все это прозрачно для юзера.

Stateless, по-моему, и проще, и универсальнее. Если потом делать, например, мобильное приложение, API переписывать не придется.

Вся фишка JWT по сути только в том, что не нужно дергать БД при каждом запросе к API. Делать это придется, например, только раз в час при refresh'е токена. Больше никаких существенных преимуществ перед традиционными токенами, хранящимися в БД, нет.

Советую курить именно официальный RFC по oAuth2, а не всякие блогпосты а-ля "OAuth2 простыми словами". Сам через это прошел. RFC - самый понятный и доходчивый источник знаний.
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
5a972d181cee3290572701.png
Вот здесь
проверенный и рабочий метод. Никаких сессий!
Только проверка "протухания" токена и его обновление(обмен!) в "прозрачном" режиме.
Ответ написан
А что не так с простой базовой авторизацие
Ответ написан
TT55EE
@TT55EE
Кшендерма ерендык
Базовой авторизации достаточно
Ответ написан
Комментировать
JohnDaniels
@JohnDaniels
когда-нибудь я обязательно пойму, чем плох "обычный" подход с куками и сессиями..
Ответ написан
DirecTwiX
@DirecTwiX
"display: flex;" уже предлагали?
Долго медитировал на тему JWT и понял, что от сессий отказаться не получится.
Плюс там ещё очень много подводных камней с рефреш токенами, которые обойти крайне сложно.
cryto.net/~joepie91/blog/attachments/jwt-flowchart.png
jwt-flowchart.png
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы
22 дек. 2024, в 20:40
10000 руб./за проект
22 дек. 2024, в 20:34
3000 руб./за проект
22 дек. 2024, в 20:12
10000 руб./за проект