Last updated
Last updated
В Server-Side Apps Authorization Flow описано, как клиенты строят запрос на авторизацию к серверу авторизации.
Сервер авторизации должен проверить:
client_id соответствует корректному приложению
Если redirect_uri указан, то проверить, что он есть в зарегистрированных Redirect URIs. Если не указан этот параметр, то убедиться, что для приложения зарегистрирован только один Redirect URL (сервер будет использовать его). Если нет redirect_uri и нет указанного в запросе - это ошибка. Иначе, это может привести к .
Если response_type не указан или не равен code или token, сервер может вернуть invalid_request.
Первое, что увидит пользователь после нажатия кнопки «Войти» или «Подключиться», - это пользовательский интерфейс вашего сервера авторизации. Сервер авторизации должен решить, требовать ли пользователю входить в систему каждый раз, когда он посещает экран авторизации, или сохранять пользователя в системе в течение некоторого периода времени. Если он сохраняет сессию пользователя, то в следующий раз пользователь сможет на лету авторизоваться в сервисе без доп кликов и подтверждений (не требуя от них входа в систему каждый раз).
Однако, исходя из требований безопасности вашей службы, а также сторонних приложений, может быть желательно потребовать или дать разработчикам возможность требовать от пользователя входа в систему каждый раз, когда он посещает экран авторизации. Например, в Google API, приложения могут добавить prompt=login, для того, чтобы пользователь авторизовался, прежде, чем дать разрешение на авторизацию в стороннем сервисе.
В зависимости от grant_type, сервер вернет authorization code или access-токен.
Если запрос корректен и пользователь разрешил доступ, сервер создаст authorization code и вернет его приложению, добавив параметры code и предыдущий stateв Redirect URL. Authorization code должен иметь короткое время жизни. Спецификация рекомендует максимум 10 минут, но на практике многие сервисы устанавливают на около 30-60 секунд. Длина значения может быть любая, но должна быть задокументирована.
Вот информация, которая должна быть ассоциирована на стороне сервер с authorization code:
client_id, кто запросил этот код
redirect_uri, для которого этот код запрашивался (тк код мог запрашиваться для разных целей: для верификации или для авторизации)
User info - для какого пользователя этот токен
Expiration Date
Unique ID - нужен для того, чтобы быстро найти, использовался ли этот код ранее (может быть использован ID в database или уникальная строка)
В этом случае сервер создает access-токен и отправляет его приложению.
Всегда есть риск, что кто-то создаст страничку, похожую на вашу, и заманит туда пользователей..
Контрмеры:
Использовать https для общения с сервером авторизации, чтобы препятствовать DNS spoofing
Надо информировать разработчиков о возможности такой атаки и принимать меры, чтобы ваша страница авторизации не могла быть отрисована мобильными приложениями или в iframe-компоненте.
Надо информировать пользователей и возможности такой атаки и обучать их способам обнаружения попыток ее провести. Рассказывать, что они должны давать разрешение только тем приложениям, которым они доверяют. И что надо периодически ревьювить список приложений, которых они авторизовали, и отзывать доступ у тех, которыми они не пользуются.
Сервис может валидировать сторонние приложения прежде, чем давать пользователям их авторизовывать. Например, требовать от разработчиков привязывать свои другие акки или предоставлять удостоверяющие документы.
Атакующий использует client_id подтвержденного приложения, но использует Redirect URL на подконтрольный ресурс. Если сервер не проверяет Redirect URL, то атакующий использует response_type=token и собирает с пользователей их токены. Если клиент OAuth является публичным, то атакующий перехватывает authorization code и обменивает его на access-токен.
Другая похожая атака: атакующий spoof DNS пользователя, и регистрирует Redirect URL без https. Это позволит злоумышленнику выдать себя за корректный Redirect URL и таким образом украсть access-токен.
Сервер должен требовать зарегистрировать один или несколько Redirect URL и сверять с ними
Все Redirect URLs должны использовать HTTPs
Много кейсов можно найти в .
response_type (required)
Установлен в code
client_id (required)
redirect_uri (optional)
Вообще, рекомендуется. Куда хотим перенаправить пользователя после успешной авторизации. Обязан совпадать с Redirect URI, что мы указали при регистрации клиента OAuth
scope (optional)
Одно или несколько значений, разделенных пробелом
state (recommended)
Выполняет две функции: это ключ сессии (может использоваться как параметр состояния или для понимания, куда редиректнуть пользователя) и CSRF-токен (если для каждого запроса это значение уникально; необходимо перепроверять, что значение state не изменилость между запросом и ответом).