Интеграция oauth2 с мобильным приложением (iOS/Android)

Question

Мне нужно интегрировать OAuth2 в собственное приложение iOS и Android. Я изучал OAuth2 и мобильные приложения и нашел эту документацию - Google APIs - Using OAuth 2.0 for Installed Applications

В приведенной выше документации в основном подробно описано, как использовать конечную точку Goolge OAuth 2.0 в мобильных приложениях.

Вот что говорится в документе -

1. При регистрации приложения, необходимо указать, что приложение является установленным приложением. Это приводит к другому значению параметра redirect_uri.
2. Client_id и client_secret, полученные во время регистрации, встроены в исходный код вашего приложения. В этом контексте client_secret явно не рассматривается как секрет.
3. Код авторизации может быть возвращен вашему приложению в строке заголовка браузера или в порт http://localhost в строке запроса.

Предположим, у пользователя установлено 2 приложения на смартфоне.

App1 - законное приложение потребляя Google OAuth2.0 конечной

app2 - злонамеренный приложение

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

---

• redirect_uri может быть http://localhost URL и может содержать любой номер порта. Номер порта не является частью первоначальной конфигурации API и, следовательно, может быть любым допустимым номером порта. Кроме того, client_id (в любом случае не должен быть секретом) и client_secret не являются действительно секретными, поскольку они встроены в исходный код мобильного приложения.

Используя вышеуказанные условия, не следующие возможности -

1. Пользователь запускает app2
2. App2 перенаправляет пользователя к конечной точке Google OAuth2.0 однако в запросе, App2 включает client_id для App1 и включает в себя номер локального порта, на котором прослушивает App2.
3. Когда пользователь перенаправляется и аутентифицируется в конечной точке Google OAuth2.0, Google указывает пользователю, что «приложение App1 (законное приложение) запрашивает доступ к API/данным Google от имени пользователя», который выглядит как фишинг атака, так как пользователь может нажать «да», думая, что App1 запрашивает доступ.
4. Google OAuth2.0 затем выдаст код авторизации, чтобы App2 и App2 могли затем сделать следующий запрос, включая client_id и client_secret от App1, и получить access_token и refresh_token и продолжить доступ к пользовательским данным из Google.

---

• redirect_uri также может быть - урны: IETF: Рабочая группа по OAuth: 2,0: OOB, что означает -

Это значение сигналов на сервер Google авторизации, что код авторизации должен быть возвращен в строке заголовка браузера. Это полезно, когда клиент не может прослушивать HTTP-порт без значительной конфигурации клиента. Приложения Windows обладают этой характеристикой.

Когда это значение используется, ваше приложение может почувствовать, что страница загружена, а заголовок страницы HTML содержит код авторизации. Затем ваше приложение закрывает окно браузера, если вы хотите, чтобы пользователь никогда не видел страницу, содержащую код авторизации. Механизм для этого варьируется от платформы к платформе.

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

Мой вопрос: может ли App2 также заметить, что страница загрузила и захватила код авторизации, а затем использовала ее (до App1) вместе с client_id и client_secret для получения access_token и refresh_token. Является ли экземпляр браузера глобальным, и любое приложение может его контролировать, и вышеупомянутый сценарий атаки действителен или является экземпляром браузера как-то специфичным для приложения, так что только App1 может отслеживать или отслеживать изменения?

---

Является ли мое понимание правильным ИЛИ Я что-то не хватает? Не хватает ли каких-либо смягчающих мер для смягчения вышеупомянутых угроз? ИЛИ Являются ли вышеуказанные риски действительными, но принимаются, учитывая, что мы находимся на платформе мобильной ОС?

Что такое безопасный способ использования OAuth2.0 в мобильных приложениях? - Отобразить код авторизации на странице браузера и ввести пользователя вручную в приложение? И в этом случае частный экземпляр браузера, чтобы другое приложение не могло его контролировать и получить код авторизации, прежде чем пользователь вводит его в законную апикацию?

Любая помощь приветствуется

Спасибо и наилучшими пожеланиями,

Answer 1

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

На большинстве мобильных платформ вы можете «слушать» для перенаправления URLS (быть HTTP или некоторые пользовательские схемы)

Например, на Android можно легко создать действие для получения маркера доступа (на основе кода авторизации так ли получает с помощью перенаправления URL.

<activity android:name=".OAuthAccessTokenActivity" android:launchMode="singleTask">> 
     <intent-filter> 
      <action android:name="android.intent.action.VIEW" /> 
      <category android:name="android.intent.category.DEFAULT" /> 
      <category android:name="android.intent.category.BROWSABLE" /> 
      <data android:scheme="http" android:host="localhost" /> 
     </intent-filter> 
    </activity> 

В этом случае

http://localhost 

на мобильных платформах, таких как Android, это кажется логичным делать.

То же самое можно сделать и на iOS, но в библиотеке Google OAuth для iOS используется подход к названию страницы, если я правильно помню.

Технически нет разницы между двумя потоками. Единственное различие заключается в синтаксисе URL-адреса перенаправления, в результате чего в другом месте кода авторизации.

С точки зрения безопасности, только код авторизации бесполезен без секретности клиента OAuth2.

Наличие пользовательского кода авторизации - это то, что я не привык видеть в потоках Oauth2, но это возможно. Если вы сомневаетесь, что он добавит что-нибудь безопасное. ИМХО это только расстроит пользователя.

Это вовсе не означает, что существуют различные способы получения и обработки кода авторизации (автоматический захват кода через редиректы с LOCALHOST или пользовательских схем URI, или ручной доставки)

Answer 2

не прямой ответ на этот но для людей, которые приезжают сюда, как я, и получаю устаревший ответ. Вероятно, лучше всего начать здесь: Google have published их библиотеки OAuth Java и Scribe - это Java.