Аутентификация и потоки OAuth2 — Примеры

Пример 1 — Три клиента, один поток на всех

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

предложение: все клиенты используют поток authorization code
  серверный веб (рендеринг на сервере)   секрет клиента в конфигурации сервера
  одностраничное приложение              секрет клиента в сборке приложения
  ночная задача импорта                  пользователя нет

Решение

клиент                    хранит секрет   поток
серверный веб             да, на сервере  authorization code, код обменивают на собственные учётные данные клиента
одностраничное приложение нет             authorization code плюс дополнительный шаг доказательства
ночной импорт             да, как он сам  client credentials, без пользователя и без шага согласия

Каждый поток отвечает на вопрос, какая сторона может хранить секрет, а страница в браузере не может: всё, что попало на устройство, можно прочитать, поэтому поток, который требует от такого клиента хранить секрет, сломан по построению. Дополнительный шаг доказательства существует ровно для такого клиента, а client credentials столь же конкретен: его использование от имени пользователя подменяет личность пользователя личностью сервиса. Секрет в сборке — та ошибка, что живёт дольше всех, потому что ничего не ломается, пока кто-нибудь не откроет инструменты разработчика.

Пример 2 — Как долго украденный токен остаётся полезным

Утёкший access token всё ещё принимали шесть дней спустя. Перепишите хронологию ниже так, чтобы действие утечки было ограничено, и скажите, что решает, можно ли воспользоваться путём поддержки.

день 1  вход в систему, access token выдан, действителен 7 дней
день 3  токен предъявлен серверу ресурсов, принят
день 6  пользователь теряет роль поддержки
день 7  срок действия токена истекает

Решение

день 1   вход: access token действителен 15 минут, refresh token хранится у сервера авторизации
         каждый запрос: access token предъявляется серверу ресурсов
+15 мин  клиент обменивает refresh token на новый access token, без пользователя
         запрос возврата: разрешён, только если роль пользователя позволяет это сейчас;
         область доступа read:orders говорит, что клиент может просить, а не что может пользователь

Access token путешествует с каждым запросом, поэтому это учётные данные, которые вероятнее всего скопируют. Короткий срок жизни ограничивает ущерб, а refresh token — хранимый тщательнее, используемый только против сервера авторизации, — избавляет от повторного вопроса пользователю. Именно это делает шестидневное окно невозможным: роль изменилась на шестой день, поэтому следующее решение об авторизации отказывает в возврате, хотя токен всё ещё действителен; однако решает здесь роль, а не срок. Трактовка области доступа как роли — та ошибка, которую здесь обходят.