Server Side App Authorization Flow
About
Server-side приложения - наиболее распространенный тип приложений, которые взаимодействуют с OAuth-сервером. Исходный код недоступен публично, следовательно их client_secret приватен.
Server-side приложения используют authorization_code grant type.
Authorization Code Grant
Пример запроса Authorizaion Code
После того, как пользователь подтвердит вход, сервер сделает редирект обратно в приложение, передав параметр code и тот же параметр state, что вы передали в query-параметре (code - это не access-токен).
OAuth Security
До 2019 года, OAuth 2.0 спецификация только рекомендовала использовать PKCE-расширение для мобильных клиентов и JavaScript-приложений. Последний OAuth Security BCP сейчас рекомендует использовать PKCE и для Server-Side приложений.
Authorization Request Parameters
| Parameters | Description |
|---|---|
response_type (required) | Установлен в |
client_id (required) | |
redirect_uri (optional) | Вообще, рекомендуется. Куда хотим перенаправить пользователя после успешной авторизации. Обязан совпадать с Redirect URI, что мы указали при регистрации клиента OAuth |
scope (optional) | Одно или несколько значений, разделенных пробелом |
state (required) | Выполняет две функции: это ключ сессии (может использоваться как параметр состояния или для понимания, куда редиректнуть пользователя) и CSRF-токен (если для каждого запроса это значение уникально; необходимо перепроверять, что значение state не изменилость между запросом и ответом). |
PKCE
Если сервис поддерживает PKCE для веб-сервера, необходимо добавить PKCE challenge и challenge method. Подробнее описано в Single-Page Apps Flow и Mobile Apps Flow.
Объединяем все эти параметры в один запрос (как правило заводится на кнопку) и направляем браузер пользователя туда.
The user approves the request
Если пользователь подтверждает авторизацию, то вы получаете authorization code для дальнейшего его обмена на access-токен.
Security
Для обеспечения безопасности authorization code grant, страница авторизации должна отображаться в веб-браузере, и не должна быть встроена во всплывающее окно iframe или встроенный браузер мобильного приложения (WebView). В этом случае, пользователь не подумает, что это попытка фишинга.
Если приложение хочет использовать authorization code grant, но не может защитить client secret (native mobile apps или JavaScript SPA), то client secret не требуется для обмена authorization code в access-токен. PKCE должен использоваться вместо client secret. Некоторые сервисы все еще не могут добавить PKCE-механизм. Они вынуждены использовать Server-Side компаньона (соотв client secret остается на сервере) вместо PKCE.
Пока OAuth 2.0 спецификация не требует, чтобы Redirect URI ходил по TLS с шифрованием, но это крайне рекомендуется, в целом.
Last updated