Следует ли использовать OAuth 2.0 для тайм-аутов аутентификации?
Разработчики мобильного приложения используют период ожидания токенов OAuth 2.0, чтобы проверить, когда приложение должно повторно аутентифицироваться на сервере.
Это противоречит моему пониманию правильного использования токенов OAuth 2.0, хотя я не совсем уверен, что прав.
Мое понимание:
OAuth касается не аутентификации, а авторизации, например. может ли это устройство получить доступ к какому-либо ресурсу на сервере от имени пользователя. Аутентификация логически предшествует авторизации и заключается в подтверждении того, что пользователь является тем, кем он себя называет.
Таким образом, пользователь представляет учетные данные (имя пользователя и пароль), и сервер подтверждает, что да, этим пользователем является Боб.
Приложение, в которое вошел Боб, хочет получить доступ к некоторым ресурсам на сервере, на котором Боб прошел аутентификацию, например к данным из API. Таким образом, приложение запрашивает токен OAuth, и он предоставляется, и одним из его атрибутов является срок его существования. Приложение и сервер обмениваются ключами, и данные между приложением и сервером шифруются с помощью ключа.
Злоумышленник, читающий незашифрованное сообщение, не сможет расшифровать его без ключа. Однако, если злоумышленник сможет получить ключ, он сможет.
Вот тут-то и начинается конец жизни токена OAuth. Мы не хотим использовать один и тот же токен (ключ) OAuth вечно, потому что, если злоумышленник смог получить этот токен, он может навсегда расшифровать наше общение. Если же мы будем обновлять токены каждые х часов, то они могут устареть информацию только на х часов (скажем, 2 часа).
Я не думаю, что срок действия токена OAuth должен быть связан с тем, как долго пользователь остается аутентифицированным. Это просто зависит от разработчиков. В нашем случае, если у пользователя есть какая-то защита устройства (например, код доступа), мы можем позволить ему оставаться аутентифицированным в течение длительного времени (например, месяцев). Если у них нет защиты устройства, я хочу заставить их повторно аутентифицироваться после разумного периода бездействия, может быть, 24 часа.
Правильно это или нет, и если нет, то какие части.
Заранее спасибо.
Брайан
Ответы 1
Ваше понимание OAuth 2.0 верное. В очень абстрактной форме протокол определяет способ получения токенов, которые клиент может использовать для связи с защищенной конечной точкой.
RFC6749 предписывает использование TLS при обмене данными с сервером авторизации (получение токена), а также при его использовании для API/защищенной конечной точки (использование токена носителя, как определено в RFC6750). Это защищает токен от атак в пути.
Рекомендуется, чтобы токен доступа OAuth имел короткий срок службы. Это сделано для того, чтобы избежать кражи токенов, а также их неправильного использования клиентом. Вы можете прочитать больше о лучших практиках от RFC6819. Информацию о времени жизни токена доступа можно прочитать из здесь.
Теперь о выборе правильного срока службы. Как вы уже поняли, использование токена обновления является желательным подходом к обновлению токенов доступа вместо использования долговременных токенов доступа. Например, токен обновления может быть действителен в течение нескольких дней, а токен доступа — всего несколько часов.
Но помните о следующем,
+ Может ли ваше приложение получить и защитить токен обновления
Например, SPA не может получить токен обновления, так как не может хранить его в течение длительного времени. В таком случае вам нужно искать альтернативные механизмы для обновления токена доступа.
+ Используется ли токен доступа для внешнего домена
Использование токена доступа к внешнему API увеличивает вектор угрозы. Например, если у вас закрытая система (клиент и серверная часть в одном домене), вы можете подумать об увеличении времени жизни токена доступа. Но не в течение длительного периода, как 24 часа!
+ Единый вход (SSO)
Вместо использования токенов доступа с длительным сроком действия вы можете получить помощь сервера авторизации для поддержания поведения единого входа поверх браузера. Это похоже на «запомнить меня», которое вы видите в современных диалогах входа в систему. После входа в систему браузер сохраняет файл cookie, который сохраняется в течение некоторого времени (например, - неделю). В следующий раз, когда вы будете использовать процесс получения токена OAuth, ваш сервер авторизации обнаружит это состояние входа в систему, поэтому диалог входа будет пропущен. Конечно, такой подход должен определяться точными требованиями безопасности/политики.
В заключение, используйте токены доступа с сокращенным сроком службы. Использование токена обновления является желательным подходом для обновления токена. Но в зависимости от ситуации можно выбрать и альтернативу.