Misanthropist
@Misanthropist
Web-developer

Где и стоит ли хранить данные авторизации через OAuth2 и откуда их брать при следующих запросах?

Есть сервер API, на котором крутится BShaffer OAuth 2 Server (https://github.com/bshaffer/oauth2-server-php).
И есть веб-приложение, которое использует OAuth2-клиент от PHP League (https://github.com/thephpleague/oauth2-client).

Пользователь логинится в веб-приложении, используя форму логин/пароль. Я засылаю из в oauth2-сервер, обратно получаю access_token, refresh_token, expire.

Допустим, access_token я могу сохранить в сессии. Ну, может expire еще. Но хранить там refresh_token что-то не очень хочется ибо слишком не секьюрно.

Может кто подсказать, как проверить корректность access_token, refresh_token и expire при, например, следующем запросе к API? И как обновлять access_token если не хранить refresh_token? Поделитесь опытом реализаций, плиз.
  • Вопрос задан
  • 1237 просмотров
Пригласить эксперта
Ответы на вопрос 3
Stalker_RED
@Stalker_RED
Хранить в базе данных, или спрашивать у пользователя пароль снова и снова.
Ответ написан
Комментировать
webinar
@webinar
Учим yii: https://youtu.be/-WRMlGHLgRg
В бд к данным юзера
Ответ написан
Комментировать
Misanthropist
@Misanthropist Автор вопроса
Web-developer
Ну, oauth2-сервер, ясное дело, может в БД залезть. А вот приложение доступа к базе не имеет. Приложению доступны localstorage, cookie и, может быть, session. Ну, чисто теоретически, можно поставить memcache. И то, не очень бы хотелось приложение привязывать к бэкэнду. Т.е. по сути имеем для хранения/получения информации: локальное хранилище, куки и запросы к API, пока действует токен доступа.

Чтобы не спрашивать пароль снова и снова - я храню в сессии access_token. Однако, любой пользователь с этой сессионной кукой получит доступ к access_token. А если там же хранить еще и refresh_token - пользователь получает нелимитированный по времени доступ к API. Что в общем-то не очень хорошо.
Ответ написан
Ваш ответ на вопрос

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

Похожие вопросы