Следует ли использовать OAuth 2.0 для тайм-аутов аутентификации?

Question

Разработчики мобильного приложения используют период ожидания токенов OAuth 2.0 для проверки необходимости повторной аутентификации приложения на сервере.

Это противоречит моему пониманию правильного использования токенов OAuth 2.0, хотя я не совсем уверен, что я прав.

Мое понимание:

OAuth не оаутентификация, но с авторизацией, например, может ли это устройство обращаться к какому-либо ресурсу на сервере от имени пользователя.Аутентификация логически предшествует авторизации и является подтверждением того, что пользователь является тем, кем, по его словам, он является.

Таким образом, пользователь представляет учетные данные (имя пользователя и пароль), и сервер аутентифицирует, что да, этот пользователь - Боб.

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

Злоумышленник, читающий открытый текст, не сможет декодировать его без ключа.Однако, если злоумышленник сможет получить ключ, он сможет.

Именно здесь наступает конец жизни токена OAuth. Мы не хотим вечно использовать один и тот же токен (ключ) OAuth, потому что если злоумышленник смог получить этот токен, он может расшифровать наше общение навсегда,Однако если мы обновляем токены каждые x часов, то они могут расшифровать информацию только за x часов (скажем, 2 часа).

Я не думаю, что время истечения токена OAuth должно быть связано с тем, как долго пользователь остается аутентифицированным.Это просто зависит от разработчиков.В нашем случае, если у пользователя есть какая-то защита устройства (например, код доступа), мы можем позволить им оставаться аутентифицированными в течение длительного времени (например, месяцы).Если у них нет защиты устройства, я хочу заставить их пройти повторную аутентификацию после разумного периода бездействия, может быть, 24 часа.

Это правильно или нет, и если нет, то какие части.

Заранее спасибо.

Брайан

Answer 1

Ваше понимание OAuth 2.0 правильное. Очень абстрактно, протокол определяет способ получения токенов, который может использоваться клиентом для связи с защищенной конечной точкой.

RFC6749 предписывают использование TLS при обмене данными с сервером авторизации (получение токена), а также при его использовании против API / защищенной конечной точки (использование токена носителя, как определено в RFC6750 ). Это защищает токен от транзитных атак.

Рекомендуется, чтобы токен доступа OAuth имел короткий срок службы. Это делается для того, чтобы избежать кражи токенов, а также злоупотребления токенами, которые могут быть выполнены клиентом. Вы можете прочитать больше о лучших методах из RFC6819 . Сведения о сроке службы токена доступа можно прочитать по здесь .

Теперь о выборе правильного времени жизни. Как вы уже поняли, использование токенов обновления - это желательный подход к обновлению токенов доступа вместо использования долгосрочных токенов доступа. Например, токен обновления может быть действителен в течение нескольких дней, а токен доступа - только в течение нескольких часов.

Но помните о следующем,

+ Может ли ваше приложение получить и защитить токен обновления

Например, SPA не может получить токен обновления, поскольку не может хранить его в течение длительного времени. В таком случае вам нужно искать альтернативные механизмы для обновления токена доступа.

+ Используется ли токен доступа для внешнего домена

Использование токена доступа к внешнему API увеличивает вектор угрозы. Например, если у вас закрытая система (клиент и серверная часть в одном домене), вы можете подумать об увеличении времени жизни токена доступа. Но не в течение длительного периода, как 24 часа.!

+ Единая регистрация (SSO)

Вместо использования долговременных токенов доступа вы можете обратиться за помощью к серверу авторизации для поддержки единого поведения в браузере. Это похоже на «помни меня», которое вы наблюдаете в современных диалогах входа в систему. После входа в браузер сохраняются файлы cookie, которые сохраняются в течение некоторого времени (например, - неделя). В следующий раз, когда вы будете использовать поток получения OAuth-маркера, ваш сервер авторизации обнаружит это состояние входа в систему, пропуская диалог входа в систему. Конечно, такой подход должен решаться на основе точных требований безопасности / политики.

В заключение, используйте токены доступа с сокращенным сроком службы. Использование токенов обновления является желательным подходом для обновления токенов. Но в зависимости от ситуации вы также можете выбрать альтернативы.