Приложение может продлять авторизацию до тех пор, пока оно обращается к сервису хотя бы раз в месяц. Вот примерное описание механизма (на основе
1. При помощи client_id приложение стандартным способом получает параметр code, требуемый для получения авторизационного токена.
2. При помощи clent_id, client_secret и code приложение получает параметры access_code и refresh_token.
3. При помощи access_code приложение совершает запросы к REST-сервису до его истечения.
4. Через час access_code истекает, и приложение может использовать полученный refresh_token для получения нового.
5. Если refresh_token еще не истек (с момента его получения не прошел месяц), то приложение получает свежий access_code и свежий refresh_token, после чего, можно перейти к шагу 3.
6. Если refresh_token уже истек, то требуется повторная авторизация с участием пользователя.
По сути, физическая авторизация пользователя требуется только на шаге 1. В итоге получаем, что если приложение используется постоянно (шаг 4 используется чаще раза в месяц), то приложение имеет возможность продлевать авторизацию не трогая пользователя сколь угодно долго.
P.S. это относится только к приложениям третьего типа, в соответствии с логическим разделением в . Приложения первого и второго типов получают и продляют авторизацию автоматически.
