- PVSM.RU - https://www.pvsm.ru -
Недавно мы в Voximplant улучшали авторизацию в SDK. Посмотрев на результаты, я несколько опечалился, что вместо простого и понятного токена их стало две штуки: access token и refresh token. Которые мало того что надо регулярно обновлять, так еще документировать и объяснять в обучающих материалах [1]. Помня, что в OAuth два токена нужны в основном из-за разных сервисов, на которых они используются (даже вопрос на stackoverflow [2] есть), а у нас такой сервис один, я несколько офигел и пошел на второй этаж вытрясать души из разработчиков. Ответ получился неожиданным. Его нет на stackoverflow. Зато он есть под катом.
При разработке приложений, общающихся с сервером, обычно вылезают следующие этапы:
Есть много разных токенов. Обычные, криптографические, «access key», «session token», разные схемы получения, использования и revoke. При этом одна из ключевых идей заключается в том, что если кто нехороший получит чужой токен, то самое неприятное, что случится — это доступ похитителя к сервису, от которого токен похищен. Пароль, тот самый, который один на все сервисы, похититель не получит. А пользователь, если поймет, что кроме него к сервису получил доступ кто-то другой, может токен отозвать. После чего получить себе новый, имея логин и пароль.
В OAuth 2 и некоторых других схемах авторизации (например, у нас [1]) есть не один, а целых два токена. Первый, access token, используется при запросах к серверу (например, при логине). У него есть два свойства: он многоразовый и короткоживущий. Наш, к примеру, живет 48 часов, а у кого-то 30 минут. Время выбирается на основании того, как используется сервис. Второй, refresh token, используется для обновления пары access и refresh токенов. У него тоже есть два свойства, обратные первому токену: он одноразовый и долгоживущий. Совсем долгоживуший, наш живет месяц.
Схема использования у токенов следующая:
Примерно так это все объяснено в документации OAuth, на Википедии, в нашей документации. И такое объяснение не отвечает на вопрос нафига?!? Зачем нужны два токена, если можно обойтись одним? В вопросе на stackoverflow [2] даны несколько объяснений уровня «ну, access token можно менее надежно хранить чем refresh token и не бояться использовать вне HTTPS соединений» или «refresh token используется для доступа к заведомо безопасному сервису, а access token'ом потом можно тыкать во всякие подозрительные места и не очень бояться, что его сользую». Это может быть разумно для авторизации через Facebook и последующего использования без HTTPS. Но у нас-то везде HTTPS! И сервис у нас тоже один, наш. Зачем нам второй токен?
Все оказалось и проще, и сложнее чем я думал. Следите за руками:
Случай 1: Боб узнал оба токена Алисы и не воспользовался refresh
В этом случае Боб получит доступ к сервису на время жизни access token. Как только оно истечет и приложение, которым пользуется Алиса, воспользуется refresh token, сервер вернет новую пару токенов, а те, что узнал Боб, превратятся в тыкву.
Случай 2: Боб узнал оба токена Алисы и воспользовался refresh
В этом случае оба токена Алисы превращаются в тыкву, приложение предлагает ей авторизоваться логином и паролем, сервер возвращает новую пару токенов, а те, что узнал Боб, снова превратятся в тыкву (тут есть нюанс с device id, может вернуть ту же пару что и у Боба. В таком случае следующее использование refresh токена превратит токены Боба в то, что изображено справа).
Таким образом, схема refresh + access токен ограничивает время, на которое атакующий может получить доступ к сервису. По сравнению с одним токеном, которым злоумышленник может пользоваться неделями и никто об этом не узнает.
Автор: Voximplant
Источник [7]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/programmirovanie/248029
Ссылки в тексте:
[1] обучающих материалах: https://voximplant.com/blog/using-tokens-to-avoid-password-save/
[2] stackoverflow: http://stackoverflow.com/questions/3487991/why-does-oauth-v2-have-both-access-and-refresh-tokens
[3] DataArt: https://habrahabr.ru/company/dataart/blog/262817/
[4] логинится: https://voximplant.com/docs/references/mobilesdk/android/com/zingaya/voximplant/VoxImplantClient.html#login(java.lang.String,%20java.lang.String)
[5] два токена: https://voximplant.com/docs/references/mobilesdk/android/com/zingaya/voximplant/VoxImplantCallback.LoginTokens.html
[6] использует: https://voximplant.com/docs/references/mobilesdk/android/com/zingaya/voximplant/VoxImplantClient.html#refreshToken(java.lang.String,%20java.lang.String)
[7] Источник: https://habrahabr.ru/post/323160/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.