Защитите код аутентификации в Oauth2 с помощью собственных приложений (Android)

Этот вопрос вряд ли связан с AppLinks assetslinks.json не выглядит для проверки

Я внедряю приложения Oauth2 на Android. Я хотел бы использовать SSO (единый вход), и у меня есть опасения по поводу AppLink для защиты кода авторизации.

Собственное приложение через браузер инициирует запрос авторизации, а затем получает ответ авторизации, содержащий код авторизации. Согласно RFC6749#section-4.1.2, код передается внутри URL:

HTTP/1.1 302 Found Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

Код авторизации — это конфиденциальная часть информации, поскольку она позволяет клиенту получить токен доступа и токен обновления, а затем получить доступ к защищенному ресурсу.

Чтобы защитить этот код, собственное приложение должно реализовывать перенаправления схемы https (RFC8252#section-7.2 и раздел-8.1). На Android это необходимо сделать с помощью файла assetslinks.json.

Но, согласно соответствующему вопросу, связано вверху, ссылки приложений на Android кажутся небезопасными на 100%, поскольку ОС может не проверять схему https.

В этом контексте, как мы должны реализовать ловушку кода авторизации Oauth2?

РЕДАКТИРОВАТЬ

По словам @benjamin anwser, AppLink не предназначен для обеспечения безопасности. Но вариант использования связанной угрозы следующий: устанавливается вредоносное приложение, которое использует «SSO Cookie», чтобы получить Auth Code и обменять его на AT+RT. Мне кажется, что ничто в процессе не может предотвратить этот случай: если applink не для безопасности, как сервер авторизации может узнать, что это приложение является вредоносным приложением?

Примечание. Под SSO-Cookie я имею в виду использование CustomTab для выполнения единого входа на Android.


android oauth-2.0 deeplink nativeapplication android-customtabs
person MalikDe    schedule 13.08.2018    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Функциональность AppLinks не гарантирует безопасность. Когда вы настраиваете файл /.well-known/assetlinks.json, он разрешает прозрачное перенаправление в приложение без какого-либо взаимодействия с пользователем. Это означает, что модальное диалоговое окно, которое обычно появляется, чтобы выбрать, какое приложение пользователь хотел бы использовать для обработки ссылки, не появится. Как вы сказали, этот механизм можно обойти, если пользователь решит обработать вашу ссылку с другим приложением или ваше приложение еще не установлено. Для этого пользователю необходимо перейти в настройки телефона:

Настройки > Приложения > выберите приложение, которое может обрабатывать ссылку Код авторизации > Открыть по умолчанию > Открывать поддерживаемые ссылки в этом приложении > выберите Всегда разрешать. Таким образом, стороннее приложение сможет перехватывать информацию, содержащуюся в вашей ссылке, в вашем случае Код авторизации.

Тем не менее, на самом деле это Проверочный ключ для обмена кодами (PKCE), что гарантирует безопасность кода авторизации. Ваш сервер должен реализовать эту функцию, чтобы предотвратить нежелательные повторы кода авторизации. Небольшое напоминание об этапах авторизации OAuth с использованием PKCE. :

  1. Клиент (приложение) вызывает конечную точку /authorization с хешированной случайной строкой и методом, который использовался для ее хеширования. Клиент сохраняет случайную строку (не хешированную), потому что она будет использоваться на шаге 3.
  2. Сервер авторизации проверяет, правильно ли пользователь ввел логин/пароль. Если все в порядке, он сохраняет хешированную случайную строку и метод хеширования, которые были отправлены в запросе. Затем сервер перенаправляет пользовательский агент в приложение с перенаправлением, содержащим Код авторизации.
  3. Чтобы получить свой токен доступа, клиент (приложение) вызывает конечную точку /token со случайной строкой, сгенерированной на шаге 1.
  4. Сервер получает запрос /token, извлекает случайную строку и хэширует ее с помощью метода, сохраненного на шаге 2. Затем сервер должен проверять, соответствует ли эта хешированная строка той, которая сохранена на шаге 2. Если строки то же самое, сервер отвечает токеном доступа и токеном обновления, в противном случае — ошибкой.

Таким образом PKCE гарантирует, что клиент, выполнивший запрос /authorization, является тем же клиентом, который выполнит запрос /token. Таким образом, даже если стороннее приложение получит ваш Код авторизации, оно не сможет использовать его для получения токенов доступа.

Для получения дополнительной информации см.: PKCE (rfc 7636) и OAuth 2.0 для нативных приложений (rfc 8252)

person Benjamin    schedule 17.08.2018
comment
Я согласен с вами насчет PKCE и хорошо знаю соответствующий RFC. Но мой вариант использования следующий: установлено вредоносное приложение и используется файл cookie SSO, чтобы получить код аутентификации и обменять его на AT+RT. Мне кажется, что ничто в процессе не может предотвратить этот случай. Под SSO-Cookie я имею в виду использование CustomTab для выполнения единого входа на Android. - person MalikDe; 19.08.2018