OAuth grant flow - истечения токенов

Question

Я разрабатываю приложение для Android, которое использует API REST Outlook. Я пытаюсь синхронизировать и обновлять календари нескольких пользователей (конференц-залы).

Мои вопросы:

1) После того, как долго первоначальный код авторизации истекает?

2) И для вместо токена обновления?

токен доступа истекает через 60 минут. Я не могу получить, если для токена обновления истекает через 6 часов, 14 дней или 90 дней.

3) Может ли конфигурация последней конфигурации? Могу ли я заставить его не истекать?

`

UPDATE: (от https://msdn.microsoft.com/en-us/library/azure/dn645542.aspx)

«Время жизни маркеров обновления не предоставляется и меняется в зависимости от параметров политики, и времени, когда субсидия код авторизации аннулирована Azure эры. приложение должно ожидать и обрабатывать случаи, когда запрос на новый токен доступа терпит неудачу. В этом случае он должен вернуться к коду, который запрашивает новый токен доступа ».

А также: (от http://blogs.msdn.com/b/exchangedev/archive/2014/03/25/using-oauth2-to-access-calendar-contact-and-mail-api-in-exchange-online-in-office-365.aspx) «Обновить маркеры не имеют указанные сроки службы Как правило, время жизни токенов обновления сравнительно давно, однако, в некоторых случаях обновить маркеры истекает, будут отменены или не имеют достаточных привилегий для.. требуемое действие Клиентское приложение должно ожидать и обрабатывать ошибки, возвращаемые конечной точкой выпуска маркеров правильно. Когда вы получаете ответ с обновленной токенной ошибкой, отбрасываете текущий токен обновления и запрашиваете новый код авторизации или токен доступа. В частности, при использовании токена обновления в потоке грантов авторизационного кода, если вы получаете ответ с кодами ошибок взаимодействия или запроса invalid_grant, отбросьте токен обновления и запросите новый код авторизации ».

Как я могу гарантировать, что в моем приложении всегда будут присутствовать все пользователи?

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

Благодаря

Answer 1

Ответы:

1. несколько минут. Точное значение является детальностью реализации и может меняться в любой момент. Вы должны сделать все возможное, чтобы выкупить код, как только вы его получите.
2. см. http://www.cloudidentity.com/blog/2015/03/20/azure-ad-token-lifetime/
3. На сегодняшний день пределы срока службы не могут быть изменены. Мы работаем над функциями, которые предоставят вам больше контроля, но у нас нет ETA для обмена на данный момент.

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

Если токен обновления истекает, вы должны планировать интерактивную проверку подлинности. Обратите внимание, что токен обновления также может быть аннулирован путем аннулирования согласия, который будет обеспечивать интерактивность во всех случаях.

Answer 2

Что вы можете сделать, так это получить refresh_token и access_token. Получите доступ к тому, что вам нужно через access_token, если это не удается, тогда предположим, что оно истекло, и используйте refresh_token для обновления access_token. Если пользователь меняет свой пароль (или, может быть, есть другие случаи), вы начинаете с первого.

Чтобы получить refresh_token, я думаю, вам нужно добавить offline_access в свою область. Что-то вроде этого:

USER_OAUTH2_AUTHORIZE_URL 
    + "?client_id=" + config.getClientId() 
    + "&redirect_uri=" + getOutlookLoginRedirect(request) 
    + "&response_type=code" 
    + "&scope=https%3A%2F%2Foutlook.office.com%2Fmail.send%20" + 
      "https%3A%2F%2Foutlook.office.com%2Fmail.readwrite%20" + 
      "offline_access%20openid%20email%20profile"