Server Side App Authorization Flow

About

Server-side приложения - наиболее распространенный тип приложений, которые взаимодействуют с OAuth-сервером. Исходный код недоступен публично, следовательно их client_secret приватен.

Server-side приложения используют authorization_code grant type.

Authorization Code Grant

Пример запроса Authorizaion Code

https://authorization-server.com/oauth/authorize
    ?client_id=a17c21ed
    &response_type=code
    &state=5ca75bd30
    &redirect_uri=https%3A%2F%2Fexample-app.com%2Fauth
    &scope=photos

После того, как пользователь подтвердит вход, сервер сделает редирект обратно в приложение, передав параметр 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)	Установлен в code
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 с шифрованием, но это крайне рекомендуется, в целом.