OAuth 2.0: внедрение авторизации через провайдера

Прямой ответ

OAuth 2.0 делегирует авторизацию провайдеру, поэтому приложение не хранит пароли пользователей, а получает токен доступа.

from authlib.integrations.starlette_client import OAuth

oauth = OAuth()
oauth.register(
    name="google",
    client_id="your-client-id",
    client_secret="your-client-secret",
    server_metadata_url=""
)

Поток Authorization Code обменивает код на токен, поэтому пароль пользователя не передаётся приложению. О JWT аутентификации — в статье про JWT аутентификацию.

Потоки авторизации, токены и scopes

OAuth 2.0 определяет несколько потоков авторизации, поэтому выбор потока зависит от типа приложения и требований безопасности.

Authorization Code. Поток для веб-приложений с сервером, поэтому код обменивается на токен на сервере, а не в браузере.

Client Credentials. Поток для сервис-сервисного взаимодействия, поэтому токен получается без участия пользователя.

Refresh Token. Поток для продления access token, поэтому повторная аутентификация не требуется.

Практическое следствие: использование Implicit потока в SPA небезопасно, поэтому токен передаётся через браузер и может быть перехвачен.

Отдельный аспект — scopes. Scopes определяют, какие разрешения запрашиваются, поэтому доступ ограничивается необходимыми разрешениями.

Три признака некорректной реализации OAuth 2.0.

Использование Implicit потока в SPA. Токен передаётся через браузер, поэтому может быть перехвачен.

Отсутствие проверки scopes. Все разрешения запрашиваются, поэтому доступ не ограничивается.

Хранение client_secret в коде. Секрет попадает в систему контроля версий, поэтому доступ к нему не ограничивается.

О методах аутентификации — в статье про методы аутентификации API; о JWT и OAuth — в статье про JWT и OAuth.

Проверка scopes и диагностика

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

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

Фиксация в логе. Запись авторизации позволяет определить, когда и кем был получен токен при диагностике.

Разделение по окружениям. Client ID и secret разработки и продакшена различаются, поэтому окружения разделяются.

Практическое следствие: отсутствие проверки scopes приводит к тому, что все разрешения запрашиваются, поэтому доступ не ограничивается.

Практика: настройка OAuth 2.0

1. Используйте Authorization Code поток для веб-приложений. Код обменивается на токен на сервере, поэтому токен не передаётся через браузер.

2. Не используйте Implicit поток в SPA. Токен передаётся через браузер, поэтому может быть перехвачен.

3. Проверяйте scopes при запросе. Ограничение scopes предотвращает запрос избыточных разрешений.

4. Не храните client_secret в коде. Секрет в коде попадает в систему контроля версий, поэтому доступ к нему не ограничивается.

5. Используйте защищённое хранилище для client_secret. Доступ к секрету ограничивается настройкой прав.

6. Фиксируйте авторизацию в логе. Запись авторизации позволяет определить, когда и кем был получен токен.

7. Используйте refresh tokens для продления. Refresh token позволяет получить новый access token без повторной аутентификации.

Рекомендации:

1. Не используйте Implicit поток в SPA. Токен передаётся через браузер, поэтому может быть перехвачен.
2. Учитывайте scopes при настройке. Ограничение scopes предотвращает запрос избыточных разрешений.
3. Сопоставляйте поток с типом приложения. Authorization Code для веб-приложений, Client Credentials для сервис-сервисного взаимодействия.
4. Фиксируйте авторизацию в ошибке. Признак в записи ошибки позволяет определить, когда был получен токен.
5. Пересматриваем scopes при изменении требований. Новый scope требует добавления в запрос.

Практический сценарий: токен был перехвачен в SPA

Контекст: токен был перехвачен в SPA, поэтому злоумышленник получил доступ к API.

1. Диагностика. Проверка показала, что использовался Implicit поток в SPA. Токен передавался через браузер, поэтому был перехвачен злоумышленником.
2. Причина. Implicit поток передаёт токен через браузер, поэтому токен может быть перехвачен.
3. Действия. (а) Перешли на Authorization Code поток с PKCE, чтобы токен обменивался на сервере; (б) проверили scopes, чтобы ограничить разрешения; (в) перенесли client_secret в защищённое хранилище, чтобы доступ к нему ограничивался; (г) добавили фиксацию авторизации в логе для диагностики; (д) настроили refresh tokens для продления без повторной аутентификации.
4. Результат. Токен обменивается на сервере, поэтому перехват через браузер не выполняется.

Вывод: Implicit поток передаёт токен через браузер, поэтому токен может быть перехвачен. Authorization Code поток с PKCE обменивает токен на сервере, поэтому перехват через браузер не выполняется.

Практический сценарий: токен был перехвачен в SPA

Контекст: токен был перехвачен в SPA, поэтому злоумышленник получил доступ к API.

1. Диагностика. Проверка показала, что использовался Implicit поток в SPA. Токен передавался через браузер, поэтому был перехвачен злоумышленником.
2. Причина. Implicit поток передаёт токен через браузер, поэтому токен может быть перехвачен.
3. Действия. (а) Перешли на Authorization Code поток с PKCE, чтобы токен обменивался на сервере; (б) проверили scopes, чтобы ограничить разрешения; (в) перенесли client_secret в защищённое хранилище, чтобы доступ к нему ограничивался; (г) добавили фиксацию авторизации в логе для диагностики; (д) настроили refresh tokens для продления без повторной аутентификации.
4. Результат. Токен обменивается на сервере, поэтому перехват через браузер не выполняется.

Вывод: Implicit поток передаёт токен через браузер, поэтому токен может быть перехвачен. Authorization Code поток с PKCE обменивает токен на сервере, поэтому перехват через браузер не выполняется.

FAQ

Что такое OAuth 2.0? Протокол авторизации, делегирующий авторизацию провайдеру. Приложение не хранит пароли пользователей, а получает токен доступа.

Какой поток использовать для SPA? Authorization Code с PKCE. Implicit поток передаёт токен через браузер, поэтому может быть перехвачен.

Зачем нужны scopes? Scopes определяют, какие разрешения запрашиваются. Ограничение scopes предотвращает запрос избыточных разрешений.

Как безопасно хранить client_secret? В защищённом хранилище с ограниченным доступом. Секрет в коде попадает в систему контроля версий, поэтому доступ к нему не ограничивается.

Источники: OAuth.net, RFC 6749, Authlib — ссылки в шапке.