Authorization Flow

Authorization Request

В Server-Side Apps Authorization Flow описано, как клиенты строят запрос на авторизацию к серверу авторизации.

Authorization Request Parameters

Parameters	Description
response_type (required)	Установлен в code
client_id (required)
redirect_uri (optional)	Вообще, рекомендуется. Куда хотим перенаправить пользователя после успешной авторизации. Обязан совпадать с Redirect URI, что мы указали при регистрации клиента OAuth
scope (optional)	Одно или несколько значений, разделенных пробелом
state (recommended)	Выполняет две функции: это ключ сессии (может использоваться как параметр состояния или для понимания, куда редиректнуть пользователя) и CSRF-токен (если для каждого запроса это значение уникально; необходимо перепроверять, что значение state не изменилость между запросом и ответом).

Verifying the Authorization Request

Сервер авторизации должен проверить:

• client_id соответствует корректному приложению

• Если redirect_uri указан, то проверить, что он есть в зарегистрированных Redirect URIs. Если не указан этот параметр, то убедиться, что для приложения зарегистрирован только один Redirect URL (сервер будет использовать его). Если нет redirect_uri и нет указанного в запросе - это ошибка. Иначе, это может привести к "open redirector attack".

• Если response_type не указан или не равен code или token, сервер может вернуть invalid_request.

Requiring User Login

Первое, что увидит пользователь после нажатия кнопки «Войти» или «Подключиться», - это пользовательский интерфейс вашего сервера авторизации. Сервер авторизации должен решить, требовать ли пользователю входить в систему каждый раз, когда он посещает экран авторизации, или сохранять пользователя в системе в течение некоторого периода времени. Если он сохраняет сессию пользователя, то в следующий раз пользователь сможет на лету авторизоваться в сервисе без доп кликов и подтверждений (не требуя от них входа в систему каждый раз).

Однако, исходя из требований безопасности вашей службы, а также сторонних приложений, может быть желательно потребовать или дать разработчикам возможность требовать от пользователя входа в систему каждый раз, когда он посещает экран авторизации. Например, в Google API, приложения могут добавить prompt=login, для того, чтобы пользователь авторизовался, прежде, чем дать разрешение на авторизацию в стороннем сервисе.

The Authorization Response

В зависимости от grant_type, сервер вернет authorization code или access-токен.

Authorization Code Response

Если запрос корректен и пользователь разрешил доступ, сервер создаст 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 или уникальная строка)

Implicit Grant Type Response

В этом случае сервер создает access-токен и отправляет его приложению.

Security

Много кейсов можно найти в OAuth 2.0 Thread Model and Security Considerations.

Phishing Attacks

Всегда есть риск, что кто-то создаст страничку, похожую на вашу, и заманит туда пользователей..

Контрмеры:

• Использовать https для общения с сервером авторизации, чтобы препятствовать DNS spoofing

• Надо информировать разработчиков о возможности такой атаки и принимать меры, чтобы ваша страница авторизации не могла быть отрисована мобильными приложениями или в iframe-компоненте.

• Надо информировать пользователей и возможности такой атаки и обучать их способам обнаружения попыток ее провести. Рассказывать, что они должны давать разрешение только тем приложениям, которым они доверяют. И что надо периодически ревьювить список приложений, которых они авторизовали, и отзывать доступ у тех, которыми они не пользуются.

• Сервис может валидировать сторонние приложения прежде, чем давать пользователям их авторизовывать. Например, требовать от разработчиков привязывать свои другие акки или предоставлять удостоверяющие документы.

Clickjacking

Redirect URL Manipulation

Атакующий использует 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